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1. INTRODUCTION 


1.1 GENERAL 

This final report serves to document the results and, findings of a study 
undertaken to define means of optimizing the Space! ab experiment data 
system by interactively manipulating the flow of data. This Spacelab 
User Interaction Study was performed by IBM for the Marshall Space Flight 
Center (MSFC). 

The Spacelab User Interaction Study was initiated by a prior study performed 
by IBM for MSFC in which a total source to user data flow was defined 
for Spacelab experiment data. It was recognized during this work that 
the total volume of data to be generated by Spacelab experiments would 
far exceed the existing data processing capability. This fact gave reason 
for initiating a separate study for determining the feasibility of inter^ 
acting in or near real time with the data to reduce the volume while 
maintaining the quality of the data. 

The interaction study project was organized into three phases. The first 
two phases have been completed and previously documented. This document 
presents the results of the third and final phase of the study. 

1.2 PHASE I REVIEW 

The first phase of the User Interaction Study was intended to define an 
interactive user interface by presenting interaction implementation concepts. 
Interim milestones included establishing the need for interactions developing 
candidate approaches and concepts, and identifying criteria for the selection 
of interaction techniques. Figure 1.1-1 illustrates the flow of the Phase I 
study. The approach was to determine Spacelab payload experiment definitions, 
evaluate documented data system requirements and constraints, and investigate 
user requirements in order to qualify the interaction idea. 
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Once the need for interaction was established, concepts were developed 
for implenientation of an interaction system. Various candidate configura- 
tions were considered involving onboard versus ground, automated versus man- 
tended, and software versus hardware options. An interaction system design 
concept was selected which assumed an onboard experimenter v/ith ground 
monitor. This system configuration incorporates characteristics of all 
the candidate options and was used in subsequent study phases as the 
baseline system design configuration. Figure 1,2-1 depicts the onboard/ 
ground combination system for experiment control. 

The Phase I study results were documented as part of the final report 
for a Study entitled "Space Station Data Flow, Amended For: Shuttle/Spacelab 
Experiment Payloads andSpacelab/Interaction" (IBM No. 74W-00140) and dated 
May 1974. ' 

1.3 PHASE II REVIEW 

Phase II of the study was devoted to the identification and definition of 
interaction techniques applicable to the Spacelab experiment data flow. 

A specific approach was adopted which involved the selection of baseline 
payloads whose associated data flows would serve as a vehicle for the 
demonstration of interaction techniques. The baseline payloads were 
selected after having identified interaction amenable sensors and experiments. 

The payloads selected as baseline were SO-Ol-S (Solar Physics) and E0-06-S 
(Earth Observations). These payloads appeared also to be the data drivers 
for their respective disciplines. Data flows were drawn for the two payloads 
and, after having researched the applicable documentation and sampled the 
available experience references, the interaction techniques were defined. 
Figure 1.3-1 depicts the flow of the Phase II study and its relationship to 
Phases I and III, 

The end item for the Phase II ivtudy was a description of candidate interaction 
techniques and their application to the baseline data flows. These results 
were reported in a formal presentation given at MSFC on May 16, 1975, and the 
accompanying document (IBM No. 75W-00093), 
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1.4 PHASE III APPROACH 


The Phase III task involved consolidating and combining the techniques 
of Interaction identified during the Phase II v/ork into interaction systems 
for each of the two baseline payloads. Each technique was evaluated for 
inclusion in the interaction system on the basis of benefit versus cost 
considerations. Questions of onboard versus ground application and 
hardware versus software implementation were approached vdth the intent of 
providing the most cost effective means of optimizing the data flow. 

The remainder of this document serves to present the Phase III task results 
and also as a final report for the User Interaction Study contract. The 
two baseline interaction systems are defined in detail complete with 
functional and operational descriptions, hardware specifications, and 
software requirements for both onboard and ground based system elements. 



2. SUMMARY 


2.1 ASSUMPTIONS AND GUIDELINES 

In the process of defining and costing the interaction systems for the 
two baseline payloads, several assumptions and guidelines were necessary. 

The basic data requirements for each of these payloads were assumed to 
be as presented in the Level B SSPD dated July, 1974. Any changes adopted 
were done so only after telephone contact with the appropriate experiment 
managers. 

The interaction systems were designed to be compatible with the CDMS 
configuration presented in the Payload Accommodation Handbook, dated May, 
1975. The existing CDMS facilities were utilized as much as was practical 
in the system definition work. The baseline CDMS definition was not altered, 
however, to effect the integration of the interaction system elements into 
the onboard data system. The interaction system elements are presented 
as deltas from this baseline CDMS. 

While the data management for the E0-06-S payload involved only onboard 
activities (no data transmitted to ground), the SO-Ol-S payload also involved 
ground operations. In the absence of a Payload Operations Center (POC) 
definition, the ground interaction system elements were presented as require- 
ments. It was assumed that these ground system requirements could reasonably 
be expected to be accommodated by standard POC elements. 

The definition of the interaction system elements was not restricted to 
hardware state of the art. In particular, the high data generation rates 
of the payload sensors is beyond present data recording capabilities. The 
assumption was made that if the affected technologies were projected into 
the 1980's, then the associated requirements could be accommodated. 


2.2 RESULTS AND CONCLUSIONS 

The interaction study resulted in the definition of Interaction systems 
for two representative Space! ab payloads and the integration of these 
systems into the CDMS. These system definitions are supplemented with 
detailed descriptions of the constituent software and hardware elements, 
and include operational procedures and cost/benefit analyses. These 
results serve to demonstrate that given a specific payload definition, an 
interaction system can be designed to effect a data management scheme that 
optimizes scientific value of the data and the cost effectiveness of the 
data system. The conclusion is that the interaction idea has proven to 
be not only feasible, but practical, and extremely effective in reducing 
payload data costs, ' 

2.2.1 Technical Results 

This study resulted in interaction system definitions for the SO-Ol-S and 
EO-oe-S payloads. The interaction system for E0-O6-S is an onboard system 
with controls originating from the Payload Specialist Station (PSS). The 
system is designed to offer the experimenter several options for "screening" 
the data in real time to select only valid data for retention and processing. 

The scheme features both automated and manual options which involve man-in- 
the-loop visibility and controls to various degrees. The system designed 
for the SO-Ol-S payload involves both onboard operations controlled from 
the PSS and ground based operations at the POC. Basically, the system is 
configured to detect conditions which render the data invalid and eliminate 
this data prior to processing. Operational mode options enable the experimenter 
to collect data only during periods of high solar activity of significant 
scientific interest. Other features include options available to enhance 
the scientific value of collected data. 


A benefits assessment w?.^ performed to determine the merit of these inter-* 
action systems. The cost benefits for each of the two systems were deter- 
mined by differencing total systems cost from the estimated reduction in 
data processing costs. Based upon an 85% reduction in. data volumes the 
E0-06-S payload was estimated to save $1.07 million in data processing costs. 
Comparison of this figure to the total interaction system cost of $.7 million 
yields a cost savings for the first mission of $.37 million. A similar assessment 
for the SO-Ol-S system is based upon a 55% reduction in data to be processed. 

The total system cost would be $.6 million while the data processing cost 
reduction is estimated at $1.2 million. These figures yield a first mission 
cost savings of $.6 million. For both payloads, all flights subsequent to the 
first would share the interaction system development cost responsibility and 
the mors repeat missiors flown, the greater would be the cost savings per 
mission. 

Not all benefits of interaction are readily quantifiable and, consequently, 
were not included in the cost benefit calculations. This would include , 
some cost savings due to reductions in data storage, data turn-around, and 
data archiving costs. Less quantifiable savings will also be realized in 
the area of increased scientific value of the data. More accurate target 
identification, greater potential for information extraction, and data 
retakes which might eliminate repeat flights are some of the benefits 
attributable to this enhancement of the scientific value. 

2.2,2 Data S.vstems Impact 

In the process of pursuing the interaction study, several facts were 
revealed which relate to elements of the total Space! ab data flow. There 
appears to be a gross difference between the data volume and speed require- 
ments of some payloads defined in the SSPD and the data flow accommodations 
of the CDHS. Some such payloads do not include any provision for self- 
contained computing or recording facilities. It is apparent that either 


2-3 


9 


CDMS must be modified to accommodate higher data rates or the payloads 
affected must be charged with accommodating their own data processing 
requirements. In. the interest of facilitating a more optimum data flow 
through interactive controls, consideration should be given to expanding 
CDMS capabilities. The experimenter should be granted greater visibility 
of his data in real time through onboard processing. 

For those experiments which require real time downlink of the data, much 
of the interactive activity can be assigned to ground operations. The 
greater processing facilities and scientific expertise located on the 
ground make more urgent the' need for an efficient and comprehensive data 
transmission system. Indications are that for some payloads only the full 
TDRSS system capability and coverage are sufficient to support ground 
based interaction. 

The definition of the Payload Operations Center should consider the require 
ments for supporting an interactive data flow. Significant computing and 
memory storage would be necessary. POC facilities should include generous 
display options for such things as data analysis and image comparisons. 
Hardware capable of generating hard copies of image data would be necessary 
False color processing of image data along with image correction algorithms 
should also be considered. In general, the POC should offer the experiment 
manager an interactive processing capability. 

2.3 RECOMMENDATIONS 

2.3.1 General 

The research which was required by the interaction study fostered some 
suggestions for optimizing the effectiveness of the data system. The most 
significant of these include: 
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f Force payload sensor design to consider telemetry- and data 
reduction consequences. 

• Develop secondary onboard Instrument calibration exercises. 

• Make more generous use of early pre-mission simulations of 
the data flow in the design of data system elements, 

• Establish realistic expectations in the scientific/user 
community as to the "real world" nature of their data. 

• User requirements should be more effectively incorporated into 
experiment definition. 


This interaction study has served to qualify the interaction principle as 
applied to two specific payloads. The potential for cost savings in the 
data processing area was established. The next step towards interactive 
Spacelab experiment data systems should be to either demonstrate an inter- 
active system via simulation or to expand the interaction system definition 
to be more comprehensive as applies to payloads, or both. Whichever option 
is selected, the Spacelab experiment program of the 1980's can realize very 
significant cost savings in the area of data processing if interaction is 
allowed sufficient influence in data systems design. 


2.3.2 Demonstration - 

If the alternative is selected to demonstrate interaction via simulation, 
then a Spacelab payload should be selected which is first, definitely selected 
for flight on a mission early in the Spacelab series, and second, is amenable 
to interaction. Once a payload is selected, an interaction system should 
be designed and integrated into the payload data flow. A demonstration 
plan should then be written which would include selection of a facility for 
demonstration. The final step would be to prepare the selected facility and 
the data systems simulation, and to perform the demonstration itself. 
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2.i 3.3 Interaction Systems Applications 

The interaction system definitions generated in this study could be used 
to develop more comprehensive systems. These two sensor systems could 
each be expanded to apply to all experiments in the payloads. Further 
expansion would generate interaction systems applicable to all payloads 
within their respective disciplines. Once systems were designed for each 
defined discipline, multi -discipline payloads could be. considered. 

In the final analysis, a decision would have to be made whether to generate 
a single comprehensive interaction system applicable to all payloads or 
whether to custom design separate interaction systems for each payload. In 
either case, a division of responsibility between the Spacelab and payloads 
elements for the interaction systems would be necessary. 



3. SO-Ol-S INTERACTION SYSTEM 
3.1 INTRODUCTION- 

The SO-Ol-S payload is the Design Reference Mission for the Solar Physics 
discipline. The payload experiment package consists of a variety of solar 
viewing instniments and instruments designed to measure and analyze solar 
energy emissions. The experiment objective is to detect and analyze solar 
flares and related active phenomena, to study the properties of the solar 
atmosphere, and to qualify large solar observatory instrumentation technology. 
The pallet only configuration of the Spacelab will be utilized for this 
mission. 

For the purposes of the derivation and demonstration of specific interaction 
techniques, one experiment was selected from the payload experiment 
complement. The photoheliograph was selected from the candidate sensors 
’because it appeared to be both representative of sensor qualities and also 
the data driver of the set. The photoheliograph generates solar images 
at high spatial and spectral resolution in ultraviolet, visible, and near- 
infrared wavelengths. The digitized image data is generated at the rate of 
13,4 Mbps. The instrument also generates film data at the rate of 8,000 
frames per day; however, film data is not amenable to interaction. 

In the absence of interaction, data will apparently be collected from the 

photoheliograph continuously throughout the seven day mission. The orbiter 

Ku band 50 Mbit downlink system along with the TDRSS system will be used 

to transmit the digital data to ground. High speed recorders onboard will 

buffer the data during periods of TDRSS occulta ti on. Continuous collection 
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of the data would result in approximately 6 x 10 bits of data to be 
processed. 
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The individual interaction techniques developed during the. Phase II study 
were directed towards reducing significantly the amount of data collected 
and processed. Basically, the various techniques provide a means of: 
collecting data only during periods of high solar activity i avoiding the 
collection of useless and degraded data due to the presence of pollutants 
and equipment failure; enhancing the information to data ratio of the 
processed data product. The individual techniques have been integrated 
into the SO-Ol-S data flow in an attempt to optimize that system. The 
interaction system includes both onboard elements, controlled from the 
Payload Specialist Station (PSS), and ground based elements located at 
the Payload Operations Center (POC). 

3.2 INTEGRATED SYSTEMS DEFINITION 

The data downlink capability included in the SO-Ol-S payload definition allows 
both onboard and ground based interaction with the data. The interaction 
techniques were evaluated and either eliminated from consideration or integrated 
into either the onboard or the ground based elements of the interaction 
system. The onboard elements of the interaction system are integrated into 
the existing definition of the Spacelab CDMS, Th'^ onboard interaction 
elements will be presented as a delta from the baseline CDMS configuration 
depicted in Figure 3.1-1. The ground operational center, the POC, is 
essentially undefined and, hence, the: ground based elements are presented 
as a system requirement and not as a delta from a POC system. 

3,2.1 Technique Evaluation 


Each of the techniques of interaction developed during Phase of the study 
were evaluated and analyzed on the basis of benefit versus cost, ground 
versus onboard application, and software versus hardware implementation. 

The following paragraphs contain a brief evaluation of each of these 
techniques. 
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Figure 3.1-1 FUNCTIONAL CDMS BLOCK DIAGRAM FOR PALLET ONLY MODE (BASELINE) 



















The Operational* Status Monitor was defined to monitor preselected 
engineering parameters in order to afford early detection of sensor 
failure. This technique was assigned to the ground system and combined 
with a scientific data monitor to support an operational status console. 
There did not appear to be any particular advantage to onboard application 
and the ground offered more abundant processing facilities. The scheme 
is effected with a software tolerance test driving a display console, 

r 

An Onboard Navigation Scheme was included to determine orbital intervals 
during which the sensor view of the sun is occulted by the earth. This 
scheme was located onboard due to the relative simplicity of implementation 
since all required inputs were available onboard. The scheme lended itself 
to full automation, which appeared desirable to our various information 
contacts. 

A Radiation Monitor was developed to detect excessive radiation levels 
which render the photoheliograph data invalid. The scheme was included in 
the onboard system in order to fully automate the procedure. A hardware 
radiation detector and a software tolerance test were required for imple- 
mentation. 

A Scientific Data Monitor was defined to monitor selected .scientific para- 
meters for an indication of degraded data. The scheme was assigned to 
ground processing because the high rate of scientific data generation 
would have necessitated a sampling hardware device for onboard application. 
A further advantage of ground application was the combination of the 
technique with the Operational Status Monitor to support a status monitor 
console at the POC. 

A Solar Flare Detection scheme was devised so that photoheliograph data 
collection could be keyed to the occurrance of solar flares. This 
technique was originally intended for onboard application, but the CCD 
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packages and the image comparator would have been very expensive and 
difficult to interface into the CDMS. Instead, the technique was 
assigned to ground application to be done with software in near real 
time. The excessive scientific data generation rate and limited 
computer storage capability prohibited onboard application of the soft- 
ware configuration. 

A technique for Wrap Around Recording was devised as an alternative to 
full time data transmission. The "wrap around" recorder would retain 
a 15 minute history of sensor data to supplement occasional periods of 
full transmission. The scheme is effected onboard with a magnetic tape 
recorder operated in the wrap around mode and a switch for routing the 
data. The technique is manageable from onboard or the ground via the 
command system. 

A scheme was proposed for the Detection of Data Pollutants such as noise, 
gimbal jitter, and control instability. This technique was eliminated 
due to the difficulty anticipated in detecting and measuring the 
pollutants. Hardware gimbal jitter and control instability appear to 
be very difficult to detect and the expected savings would not v/arrant 
the expense of hardware modifications and/or additions. Instrument noise 
should be corrected by routine calibration exercises. 

Monitor Sensor Outputs was a technique designed to monitor outputs from 
selected sensors in the experiment complement for an indication of solar 
activity. The data taken from the photoheliograph could then be managed 
according to the level of solar activity. The Grid-Coil imeter Acquisition 
Photometer, the X-Ray Burst Detector, the Gamma Ray Spectrometer,' 
and the Modulation Collimator would be candidate sensors for monitoring. 
The logic for monitoring these low data rate sensors would be relatively 
uncomplicated and could easily be accommodated by the onboard computer. 

The software tolerance test would be applied onboard in real time and 
would drive either an alert or energy emission measure. 
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The Data Recall System was devised to provide the experimenter with a 
capability to do image comparisons for the purpose of target identification 
and the identification of repeat or duplicate data. The scheme would 
require very significant storage capability for maintaining a library of 
reference images. Also the full data stream from the photoheliograph 
would have to be monitored. These requirements dictate that the scheme be 
implemented on the ground .based facilities. Support software and display 
hardware along with a hard copy hardware device would be required. 

A Change Detection Scheme was originally intended to be implemented into 
the onboard system but the hardware and interface requirements proved 
both difficult and expensive. The scheme was devised to generate difference 
images from any two input images. These difference images contain 
scientific information which is more readily extractable. This technique 
will be assigned to ground operations where its software and hardware 
(display and hard copy) requirements can be met. These requirements are 
similar to those for the Flare Detection scheme and the Change Detection 
scheme could easily be integrated into that system. 

Software Data Editing is a technique intended to reduce data processing 
costs by eliminating certain classes of data known to be invalid. By 
design, the technique is ground based to filter the telemetered data prior 
to processing into a user product. The software algorithms would be written 
to eliminate all zero, all ones, saturation data, etc. 

The Planned Data Rate Reductions technique was a result of scientists 
suggestions that the data collection rates might be reduced at some point 
into a mission when the scientist has established confidence in the integrity 
of the data system. Implementation would require a software routine for 
monitoring and displaying preselected parameters. Wear real time operation 
is acceptable and since the experiment principal investigator would likely 
be located on the ground, the technique was assigned to ground operations. 


The Field of View Monitor technique was suggested in response to some 
scientists expressed desire to observe the sensor field of view' in the 
same wavelength in which the sensor data is generated. Also a similar 
monitor in the visible wavelengths would expedite pointing exercises and 
target identification. The transformation elements necessary to obtain 
visible images from non-visible wavelength instruments proved expensive 
and impractical. Also, the photoheliograph generates data in the ultra*- 
violet, near-infrared, and visible wavelengths, and includes a camera 
for field of view monitoring in the visible wavelength. Hence, for chis 
application, the Field of View Monitor technique appeared unnecessary. 
However, for other payload applications, the technique is recommended for 
consideration. 

3.2.2 Functional Description 

The technique evaluations discussed in the previous section resulted in 
each technique being effected with either hardware or software and being 
applied either onboard or on the ground. The various techniques were 
then integrated into an onboard interaction system or a ground based inter- 
action system. The total interaction system is composed of onboard and 
ground based operations, each of which involves a consolidation of the 
previously developed techniques. The hardware and software elements of 
the onboard and ground based interaction systems will be discussed in 
detail in Sections 3.3 and 3.4, respectively. 

The onboard interaction system consists of a combination of hardware and 
software elements designed to make available to the experimenter options for 
eliminating useless and degraded data, and transmitting only data of 
significant scientific Interest. The experiment manager will be given 
the option of transmitting data continuously via the telemetry downlink 
or to allow full transmission of data only occasionally as dictated by 
targets of interest. The data collection and transmission mode will be 
selectable via commands originating at either the onboard or ground based 
control console. 


If the full transmission mode is selected, the data is continuously 
downlinked via TDRSS. If the choice is reduced transmission volume, 
then the sensor data is routed onto a "wrap around" or "loop" recorder. 

This method of recording continues until either the full transmission 
mode is selected or a target of interest warrants saving the existing 
data on the loop recorder and initiating a controlled period of full . 
transmission. This part of the onboard interaction system utilizes the 
control and display facilities at the PSS and is integrated into the 
Spacelab CDMS. 

The data transmission will be halted regardless of operational modes 
whenever dictated by automated schemes designed to detect excessive 
radiation levels and sensor field of view occultation by Earth/atmosphere. 

A software navigation scheme will determine sensor occultation periods 
based upon data obtained from the orbiter. Discrete outputs will be issued 
to control the data transmission switches. Another software algorithm 
will monitor the output of a hardware radiation detector. This tolerance 
test will also automatically control the data transmission switches In 
response to radiation levels. Both of these automated routines will 
feature a manual override capability. 

Still another software routine will be included to monitor* other sensors 
in the payload for an indication of solar activity. This routine will 
drive alerts and/or displays to Inform the crew/ground of solar activity 
status. 

Integration of these functions into the CDMS requires the software algorithms 
and new hardware consisting of the radiation detector and the loop recorder. 
The GDMS TV lines will be used to route the sensor FOV signal to display 
consoles at the PSS. Integration of this onboard interaction system into 
the CDMS is illustrated in Figure 3.2. 2-1* 



















The ground based irfVeraction system will require extensive monitoring and 
processing capability. The system will be designed to operate in near 
real time to process telemetered data into information necessary tor 
optimizing the total data flow. Extensive computer processing and storage 
capability complete with keyboard and display support will be required 
to implement the interaction algorithms. The system will involve the 
principal investigator or his representative effecting the interaction 
techniques utilizing facilities resident at a payload operations center 
(POC), In the absence of an accepted POC definition, the ground inter- 
action system was developed independent of POC facility limitations or 
restrictions. 

The ground system will monitor and process downlinked data from the TDRSS. 

The interaction will be performed and/or managed from a control and display 
keyboard and the various interactive options will be selectable from this 
keyboard. Figure 3. 2.2-2 illustrates ground system functions required 
for Spacelab mission support. All of these functions will be provided by 
POC personnel except the scientific data manipulation scientist, principal 
investigator and one (or more) subsystem engineers who would be provided 

space at the POC for scientific instrument support and science evaluation. 

No hardware configuration is implied in Figure 3. 2.2-2. Many configurations 
are possible, and no conflict with interaction requirements would be 
expected to occur in any specific hardware configuration. 

Interactive functions assigned to ground operations are designed to detect 
potential solar flares, generate difference images of greater scientific 
utility, monitor sensor operational status, monitor scientific data to 
validate system performance and to eliminate useless or degraded data 
from the processing operations. Upon request by the experiment manager, 
the downlinked data will be processed through a software routine designed 
to generate difference images from successive input images. The input 
images may be selected from the real time downlink or from previously 
loaded magnetic tapes. The difference images created in this manner will 
be available for display or hard copy. As an extension of this same liOftware 
package, pixel brightness levels will be monitored in order to identify and 
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monitor the most intense pixels. A tolerance test applied, to these pixels 
would serve to detect potential solar flares. 

Another software scheme included in the ground system is designed to support 
an operational status monitor console. The softv/are is designed to operate 
continuously on the downlinked data. Preselected scientific and engineering 
parameters will be subjected to tolerance tests in order to reveal sensor 
and/or data system anomalies. A similar tolerance test will be applied to 
downlinked parameters preselected by the experimenter to be indicative of 
data system validity.. Once confidence in the system integrity is established, 
the principal investigator might consider a reduction in the volume of data 
to be acquired. 

Logic is also available as part of the grr^nd system which will facilitate 
the recall of previously received or prestored images for comparison to 
present data. This would be useful for target verification and/or the 
identification of repeat data. This algorithm will share some of the logic 
with th" image differencing and flare detection algorithms and will require 
extensive storage capability. Dual displays will be required for simultaneous 
display of the images for visual comparison. This routine could also be 
useful in obtaining images for the generation of difference images. 

In order to eliminate classes of data known to be invalid, a software 
algorithm will be applied to all data downlinked prior to processing into 
a user product. This scheme does not require real time operation. The 
software tests will check for all zero, all ones, saturation data, etc. 

The software and hardware elements required to support these ground based 
interaction functions will be detailed in the following two sections. 
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3.3 HARDWARE SPECIFICATIONS 
3.3.1 Introduction 

Figure 3. 3. 1-1 illustrates the SO-Ol-S interaction system, identifying standard 
CDMS components, payload components, and components required for the selected 
interaction techniques. Three components are indicated in the latter catagory 
on the diagram, a radiation detector, 15 minutes auxiliary storage, and 
a downlink control switching capability. Functional interface connections 
are indicated between the components. 

The hardware configuration chosen permits retention of 15 minutes of preflare 
data and all flare data including periods of TDRSS blackout. No "double 
recording" of data is required (transferring data from one recorder to another) 
in the process of downlinking data, using the selected configuration. 

Tape recorder controls assumed for this mechanization are listed in Table 3.3. 1-1, 
Seven controls are required for the auxiliary storage recorder and four are 
required for the permanent storage recorder. The permanent storage recorder 
is planned to be located inside the pressurized cabin of the orbiter, permitting 
hands-on operation. Functions associated with location of desired data for 
transmission to ground: rewind, playback start and playback stop are indicated 
as manual functions since automation of data location would increase the 
complexity of the system significantly. Four functions are indicated for 
automated mode control: power ON, power OFF, record start, and record stop. 

No serious impact to the system will occur if these functions are also 
allocated to manual control. In that case, software allocated to tape recorder 
control will be used for generating displays to the payload specialist, who 
will perform the required tape recorder control functions. 

Five modes of operation of the data management system have been identified in 
Table 3.3. 1-2. Of these five, the "TDRSS Post-Occult" mode represents an 
operational duplicate of the "normal" and "flare" modes, depending on whether or 
not a flare occurred during the occultation. 
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Table 3.3. 1-1 TAPE RECORDER MODE CONTROL 


Application 


Item 

Auxiliary Storage 

Permanent Storage 

‘ ^ Notes 

Power ON 

X 

X 

• 

Power OFF 

X 

X 


Record Start 

X . ■ 

• X 


Record Stop 

X 

X 


Playback Start 

X ^ 

• • * 

Permanent storage recorder is assumed 

Playback Stop 

X 

■ • • 

to be designed for "hands-on" operation; 

Rewi nd 

X 

■ • • 

redesign for automated operation has not 
been considered. 



Tab! e 3. 3 a-2 DATA MANAGEMENT SYSTEM OPERATION SUMMARY 


Mode 

Auxiliary Recorder 

Permanent Recorder* 

Downlink 

Normal 

Record Photo heliograph 

Off 

None 

Flare 

Off 

Off 

Photoheliograph 

Post-Flare 

Playback 

Record Photoheliograph 

Auxiliary Recorder 

TDRSS Occulted 

Record Photoheliograph 

Record Photoheliograph** 

None 

TDRSS Post-Occult 

No flare in progress 

Record Photoheliograph 

Off 

None 

Flare in progress 

Off 

Off 

Photoheliograph 


*Requ1 red when flare developes while TDRSS is occulted or auxiliary recorder 1s in playback. 

**Upon detection of flare; simultaneously shut off auxiliary recorder. 


The period of TDRS5 occultation requires special consideration. If a flare 
(or any other solar activity of interest) occurs during occultation, the 
permanent recorder must be switched ON to record the activity, and the 
auxiliary recorder must be switched OFF. This will preserve 15 minutes 
of sun activity, prior to the observed flare, on the auxiliary recorder, 
while recording subsequent solar data on the permanent recorder. Following 
occultation, this data can be downlinked. 

3.3,2 Hardware Descriptions and Specifications 


Auxiliary Storage Device - A 15 minute "loop" recorder has been specified 
for the auxiliary storage device. No such recorder exists. However, a 
functional equivalent can be provided through the use of core, bubble, CCD, 
etc,, memories; or by a standard tape recorder with a reversing capability. 
Less attractive from a lost-data standpoint would be a standard tape recorder 
operated in "bursts" of 15 minutes with a tape change or rewind between 
'bursts. From a system standpoint, the auxiliary recorder has three major 
interfaces (Figure 3. 3, 1-1). 

1. Input data from the photoheliograph consists of a 13.4 Mbit 
serial stream. Two recorders being developed are candidates 
for this auxiliary storage device at the present. A GSFC 
recorder has a design goal of 240 Mbit, but consists of two 
120 Mbit recorders operated in parallel. Only a portion of 

the recorder's 60 tracks would be required for this application, 
but it is not being designed to reverse, or to operate with a 
loop of tape. The Spacelab CDMS will provide a 30 Mbit, 28 
track recorder. Error rates on both recorders are high 
1 x 10"^ and 1 X 10“°, respectively. 

2. Control discretes from the RAU are specified to control the 
recorder's mode. Eleven discrete outputs can provide this 
function. 
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3. Output data from the device is available for downlink 
telemetry when selected by the downlink control relay. 

The RAU mode control will require seven discrete outputs (see Table 3.3. 1-1); 
four additional discrete outputs will be required for permanent storage control. 

Radiation Detector - A local radiation sensor {Figure 3.3, 1-1) will be utilized 
to alert the crew of passage through radiation trapped in the earth's magnetic 
field or being dispersed into the upper atmosphere. Two examples are the 
South Atlantic Ananomly and nuclear byproducts of atomic explosions. A +_5 
volt analog output is required for compatibility with the RAU and intended 
interactive usage. 

Downlink Control Relay - Three devices must be selectable for downlink 
(Figure 3. 3. 1-1). 'The photoheliograph output can be telemetered in real 
time, the output of the permanent storage tape recorder, or the auxiliary 
storage tape recorder must be selectable. A fourth position is indicated for 
the downlink control switch; functionally this position (no TM input) can 
be mechanized by programming the Space! ab TM System' to omit the scientific 
data sampling or transmission. 

Mechanization of the downlink switching will require four discrete outputs 
from the RAU, three to latching relays for TM input selection, and one "clearing" 
command to the magnetic latch relays. 

3.3.3 System Options 

The selection of tape for the storage medium for the auxiliary storage 

device is largely a matter of economics. The optimistic estimate of CCD 

or bubble memory cost in the 1980 time frame indicates approximately O.OU 

10 

per bit- The 1.2 x 10 bits required for 15 minutes worth of storage will 
cost $1,200,000 plus development cost for this application. 
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Development cost of CCD or bubble memories will be required since clock 
rates inside the memory will typically be limited to 250 KHz, requiring 
custom parallel bit storage designs to accommodate the high input and 
output bit rates. 

Projected power and weight estimates for the CCD and bubble technologies in 

the 1980 time frame also result in unfavorable trades when compared to 

tape systems. Typical estimates of power are in the kilowatt range, and 

10 

weight around 1000 pounds for a 10 bit memory. 


3,4 SOFTWARE REQUIREMENTS 


3.4.1 Introduction 

A computer sizing activity was performed to establish onboard and ground 
computer requirements for the various interactive techniques proposed for 
the SO-01“S payload. As such* these sizing requirements expressed in terms 
of computer memory capacity and processor speed are summarized in Table 3.4-1. 

A detailed breakdown of the sizing analysis is given in subsections 3,4.4 
and 3.4.5 for performing the various functions associated with each technique. 

Throughout this exercise, an effort was made to 'delta' the interaction require 
ments from the existing CDMS as defined in the Spacelab Payload Accommodation 
Handbook, dated May 1975, This refers to sizing control and monitoring 
functions as well as the scientific data processing software. Regarding 
this effort, the following definitions were used: 

Control and Monitoring - Includes those computer functions 
which are required to properly operate and monitor the 
payload in addition to communicating with the orbiter. 

Scientific Data Processing Software - Incl udes software 
routines which operate on sensor outputs peculiar to the 
proposed techniques. 

3.4.2 Sizing Assumptions and Groundrules 
General 

• The sizings reflected for the onboard processing pertain to the 
general purpose CDMS computer whose operands are 8, 16, and 32 
bits for fixed point operations and 8 + 24 bits for floating 
point. Ground processing is assumed to be done by a computer 
similar to an IBM S/370 where each 8 bit byte is addressable. 
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Table 3.4-1 SO-Ol-S SOFTWARE SIZING REQUIREMENTS 


Techniques 

Total Storage 
{32-Bit Words) 

Processor Speed 
Data Processing 
(KAPS) 

Processor Speed 
Control & Monitoring 
(KAPS) 

Navigation Scheme 

181 

' 1.4 

1 

0.143 

Radiation Monitor 

156 

1.3 ' . 

0.150 

Loop Recording Control 

371 

1.1 

0.600 

Sensor Monitor 

677 

4.8 

0.480 

Change Only Image 
Production (Flare Detection) 

43128 

2311.5 

N/A 

Data Recall 

23776 

1279.5 

N/A , 

Station Monitor 

42881 

1541.0 

N/A 

Monitor and Display Functions 

42769 

1541.0 

N/A 

Preprocessing Editing 
Software 

41981 

963.1 

N/A 

* 





• Each onboard interacfive technique has bean sized. as an 
independent subroutine, called by an executive operating 
under Spacelab executive control. 

• All navigation and attitude update data will be provided to the 
payload by the Spacelab Pointing and Attitude Control (PAC) 
subsystem which is updated from the orbiter. 

Storage 

• Storage sizings are given in terms of the number of instructions 
and data words required to perform each function or logical 
block of code. For the onboard system, the total storage is 
determined by adding half the number of instructions to the 
number of 'data words since an instruction is 16 bits long. Data 
words are used for defining constants and memory storage areas 
which serve as data buffers. Ground total storage is simply 
the sum of the instructions and the data words. 

Speed 

• For onboard control and monitoring functions, one instruction 
is equal to 1,5 equivalent add operations. Speed requirements 
for sclent, data processing were determined as a function of 
the number of instructions required to process logical blocks 
of code in equivalent add operations. This value varies as a 
function of the amount of processing to be accomplished. Where 
not specified, one 16 bit data word is equal to 16 equivalent 
add operations. Due to the large data rates (13.4 Mbps) at 
which data is output, a significant amount of buffering on the 
ground is required. To compensate for accessing I/O devices, 

a 155^ data processing overhead rete is being assumed. In both tbe 
onboard and ground data processing, the auxiliary storage devices 
are assumed to have the capacity to hold extremely large quantities 
of data; ranging upwards to 10 -32 bit words. 
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3.4.3 Sizing Procedure 


The sizings established for the various techniques resulted from trans- 
forming functional requirements of the techniques into programmable 
functions. These functions were then flowcharted. The flowcharts served 
as the vehicle for estimating both the instructions and data words. The 
estimates themselves resulted from three sources; namely, coding recurring 
sections of some functions, updating existing code, and drawing upon 
experience in performing similar functions. 

3,4.4 Onboard Computer Sizing Analysis 

3.4.4. 1 Navigation Scheme - This interactive technique monitors vehicle 
position to determine at v/hat points in orbit the sensor field-of-view 
(FOV) is occulted by either the Earth or the atmosphere. Software peculiar 
to this technique must automatically direct the data transmission to an 
onboard recorder or to the ground. When occultation occurs, all data 
routing or transmission is halted; otherwise, data is downlinked or 
permanently recorded. This scheme should be updatable from the ground 
with a manual override feature. Expected cycle time is once per second 
and continuous throughout the experiment activation period. Table 3. 4. 4-1 
summarizes the sizing estimates. The required computer speed is shown at 

the bottom of the table. 

3. 4. 4. 2 Radiation Monitor - This Interactive technique must access and 
process radiation data as generated by the radiation detector. This 
radiation data *s compared to pre-established tolerance limits. When these 
limits are exceeded, all data transmission or recording is halted. Continuous 
testing throughout the experiment activation period is required, and once 

the radiation level becomes acceptable again, data transmission or recording 
is re-initiated. The normal cycle time for this technique is once per 
second. Table 3. 4. 4-2 presents the sizing requirements for the radiation 
monitor. 
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Table 3. 4.4-1 NAVIGATION SCHEME 


STORAGE REQUIREMENTS 


DATA PROCESSING 


Functions 

Instructions 
(16 Bit) 

Data 

(32 Bit Wd) 

Total Storage 
(32 Bit Wd) 

Standard Linkage 

24 

20 

32 

Access Vehicle Position and 
Velocity Parameters and Make 
Required Calculations 

52 

10 

36 

Access Stored Ephem Data and 
Make Required Calculations 

50 

5 

30 

Check Sensor FOV for Occultation 

6 

2 

5 

Halt Transmission 

6 

0 

3 

Transmit or Record 'Data 

10 

2 

7 

Standard Return Logic 

20 

0 

10 

SUBTOTAL 

168 

39 

123 

CONTROL AND MONITORING (ORBITER COMMUNICATIONS) 



Assure Instrumentation Control 

75 

0 

38 

Provide Filtered Vehicle Rates 
and Attitude Information 

20 

10 

20 

SUBTOTAL 

95 

10 

58 

TOTAL 

263 

49 

181 


SPEED REQUIREMENTS 

DATA PROCESSING: 

speed = KAPS 

plus 15% overhead .187 KAPS 

TOTAL REQUIREMENTS = 1.435 KAPS 

CONTROL AND MONITORING 

Speed = 95 X 1.5 = 0.143 KAPS 

*Total number of data processing bits, assuming 16 equivalent add operations 
per 16 bit data word. 
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3. 4. 4-2 RADIATION MONITOR 


DATA. PROCESSING 


STORAGE REQUIREMENTS 


Functions 

Instructions 
(16 Bit) 

Data 

(32 Bit Wd) 

Total Storage 
(32 Bit Wd) 

Standard Linkage 

24 

20 

32 

Determine Radiation Level 
(Access Analog Radiation Value) 

15 

5 

13 

Perform Radiation Level 
Acceptance Test 

10 

4 

9 

Set Up to Transmit or 
Record Data 

20 

4 

14 

Halt Transmission or Recording 

12 

2 

8 

Standard Return Logic 

20 

0 

10 

SUBTOTAL 

101 

35 

86 

CONTROL AND MONITORING (ORBITER COMMUNICATIONS) 



Assure Instrumentation Control 

100 

20 

70 

SUBTOTAL 

100 

20 

70 

TOTAL 

201 

55 

156 


SPEED REQUIREMENTS 

DATA PROCESSING 

Speed = ^1120 16^ ^ ^^3^20 KAPS 

plus 15% overhead .168 KAPS 

TOTAL REQUIREMENT 1.288 KAPS 

CONTROL AND MONITORING 

Speed = 100 X 1.5 ^ 0.150 KAPS 


*Total number of data processing bits, assuming 16 equivalent add operations 
per 16 bit data word. 
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3. 4. 4. 3 Loop Recording Control - Software to facilitate routing data 
either onto or around the loop recorder is required. This technique 
should provide for the receipt of onboard or ground signals for issuing 
command discretes to dump recorded data onto the permanent recorder, 
downlink it directly, or change transmission mode. Transmission modes are 
defined as loop recording, permanent recording, and telemetry downlink. 

The sizing requirements for this technique are given in Table 3, 4.4-3. 

3. 4. 4. 4 Sensor Monitor - This technique was defined to provide the experi- 
menter with a capability for monitoring solar activity. Two sensors other 
than the photoheliograph will be used. Sensor data will be available via 
the RAU for processing and later for transmission to the Payload Specialist 
Station to alert the crew for transmission mode changes if the solar activity 
level reaches certain limits. Tolerance limit update capability should 

be provided as a crew option. Normal cycle time for this technique is 
once per second throughout the experiment activation period. Table 3. 4. 4-4 
shows the sizing requirements for the sensor monitor. 

3.4.5 Ground Computer Sizing Analysis 

3. 4. 5.1 Change Only Image Production (Flare Detection) - This interactive 
technique consists of two phases; one to generate changes or differences 
in any two downlinked images, and the other to identify and isolate a solar 
flare. The differenced images of the first phase should be generated for 
near real time display and also for hard copying at the experimenter’s 
request. The final output medium of this phase should be an ultra-high 
density (UHD) tape containing only the differenced images. 

Second phase processing involves examining successive frames of image data 
to check for significant brightness levels of individual pixels. This 
examination or screening process continues until the brightest 100 pixels 
within each frame are identified. By comparing these 100 pixels to pre- 
established tolerance limits, possible flares are identified. When a 
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Table 3. 4. 4-3 LOOP RECORDER CONTROL 


DATA PROCESSING 


STORAGE REQUIREMENTS 


Functions 


Instructions 
(16 Bit) 


• Data 
(32 Bit Wd) 


Total Storage 
(32 Bit Wd) 


Standard Linkage 

24 

20 

32 

Determine Transmission or 
Recording Mode 

20 

5 

15 

Set Up to Either Transmit 
or Record Data 

20 

4 

14 

Standard Return Logic 

20 

0 

10 

SUBTOTAL 

84 

29 

71 

CONTROL AND MONITORING (ORBITER COMMUNICATIONS) 



Assure Instrumentation Control 

150 

40 

115 

Perform Image Motion Compensation 

250 

60 

185 

SUBTOTAL 

400 

100 

300 

TOTAL 

484 

129 

371 


SPEED REQUIREMENTS 


DATA PROCESSING 

Speed = | ^92S _ 16j 

plus 15% overhead 
TOTAL REQUIREMENT 

CONTROL AND MONITORING 

Speed = 400 x 1.5 


0.928 KAPS 

■139 KAPS 
1.067 KAPS 

0.600 KAPS 


*Total number of datarprocessing bits, assuming 16 equivalent add operations 
per 16 bit data word. 
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Table 3. 4. 4-4 SENSOR MONITOR 


STORAGE REQUIREMENTS 


DATA PROCESSING 




Functions 

Instructions 
(16 Bit) 

• Data 
(32 Bit Wd) 

Total Storage 
(32 Bit Wd) 

Standard Linkage 

24 

20 

32 

Access and/or Retrieve Engr. and 
Scientific Data for Sensor "X" and 
Sensor "Y" via RAU (Assumed to be 
Analog) 

20 

10 

20 

Perform Required Data Conversion 

200 

20 

120 

Process Data to Determine Solar 
Activity Level 

50 

10 

35 

Preprocess Data for Display 

60 

30 

60 

Perform Updated Cal-culations 

100 

10 

60 

Display Updated Alphanumeric 
Solar Activity Data 

60 

30 

60 

Standard Return Logic 

20 

0 

10 

SUBTOTAL 

534 

130 

397 

CONTROL AND MONITORING (ORB ITER COMMUNICATIONS) 



Assure Instrumentation Control 

200 

80 

ISO 

Perform Image Motion Compensation 

120 

. 40 

100 

SUBTOTAL 

320 

120 

280 

TOTAL 

854 

250 

677 

SPEED REQUIREMENTS 



DATA PROCESSING, 

t \ ^ 




speed = 

4.160 KAPS 




plus 15% overhead " .624 KAPS 

TOTAL REQUIREMENT 4. 784 KAPS 


CONTROL AND MONITORING 


Speed ^ 320 X 1.5 = 0.480 KAPS 

*Total number of data processing bits, assuming 16 equivalent add operations 
per 16 bit data word. 
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sufficient number of successive flare indications is found, a flare 
alarm (I/O command) is issued, and a search is made to locate the flaring 
point. This technique will be exercised in near real time during 
experiment activation periods as specified by the Principal Investigator. 
Table 3, 4. 5-1 summarizes the sizing requirements associated with this 
technique. 

3. 4.5. 2 Data. Recall - The data recall technique will require periodic 
storage- of images of dov/nl inked data as requested by the experimenter. 

These images will be recalled and compared to current real time data. A 
minimum of five frames of image data is to be stored. Keyboard accessing 
of these images is required, in addition to dual displays of the stored 
and current real time data. Processing of the data reviewed under this 
technique should also provide for pixel differencing. This technique will 
only be activated per experimenter selection. Sizing requirements are 
presented in Table 3.4. 5-2. 

3.4. 5.3 Status Monitor - This interactive technique is used to access and 
monitor preselected engineering and scientific parameters for determining 
the operational status of the experiment. Approximately 20 such parameters 
per second will be compared to their respective tolerance limits. All out- 
of-tolerance conditions will be displayed for crew inspection. Tolerance 
limits are updatable from the display keyboard. The status monitor technique 
is exercised continuously throughout the data gathering phase and in real 
time. Table 3.4. 5-3 shows the sizing requirements for this technique. 

3.4. 5.4 Monitor and Display Functions - This technique involves accessing 
and displaying key parameters upon keyboard request. These parameters will 
be selected by the experimenter to check the integrity of the image data. 

Data will be checked with regard to its generation, acquisition, and trans- 
mission. These functions can be performed in real time or non-real time from 
any previously created data tape. The sizing requirements are shown in 
Table 3. 4.5-4. 
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Table 3. 4.5-1 .CHANGE ONLY IMAGE PRODUCTION (FLARE DETECTION) 


STORAGE REQUIREMENTS , 


DATA PROCESSING 


Functions 

Instructions 
(32 Bit) 

Data 

(32 Bit Wd) 

Total Storage 
(32 Bit Wd) 

Standard Linkage 

11 

18 

29 

Prepare Data for Aux Storage 

20 

4 

24 

Create 13.4 MBPS U.H.D. Tape 

12 

2 

14 

Prep Data for Real Time Analysis 
(Data Will Pass Thru Main Memory 
of Ground Computer) 

300 

42000^^^ 

42300 

Perform Pixel Difference Analysis 

48 

4 

52 

Compare & Identify Brightest (100) 
Pixels - 

20 

4 

24 

Perform Flare Detection Analysis and 
Locate Flare Position by Accounting 
for X, Y Positions 

150 

20 

170 

Provide Hardcopy & Printout of Data 

20 

6 

26 

Preprocess Data for Display 

60 

20 

80 

Transmit Data via I OP for D-^A 
Conversion, Sync, Interlace and 
Video Display 

150 

256 

406 

Standard Return Logic 

3 

' 0 

3 

TOTAL 

794 

42334 

43128 

SPEED REQUIREMENTS 




Speed = 


1.34^^^ X 10^ X 48^^^ 
32 


plus 15% overhead 
TOTAL REQUIREMENT 


= 2010.0 KAPS 

301.5 KAPS 
2311.5 KAPS 


(1) Data brought into main memory at 1/10 instrumant output rate into 
approximately 165K of core. 

(2) Processing 1/10 of a second's accumulated data every second. 

(3) Assuming 48 equivalent add operations for each 32 bit data word processed, 
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Table 3. 4. 5-2 DATA RECALL 


STORAGE REQUIREMENTS 

DATA PROCESSING 


Functions 

Instructions 
(16 Bit) 


Data 

(32 Bit Wd) 

Total Storag 
(32 Bit Wd) 

Standard Linkage 

11 


18 

29 

Save Five Frames of Data (This 
Data is Stored on Some Auxiliary 
Storage Device; Data is Directed 
Without Holding it in Main ^ 
Storage) 

20 


4 

24 

Compare Real Time Data to These 
Five Frames (One at a Time, 
Having Two Frames of Data in 
Memory) 

32 


23190^^^ 

23222 

Output Comparison Results to Tape 

12 


(Same Core 
As Above) 

12 

Preprocess Data for Display 

60 


20 

80 

Transmit Data via I OP for D — *-A 
Conversion, Processing and 
Display 

150 


256 

406 

Standard Return Logic 

3 


0 

3 

TOTAL 

288 


23488 

23776 

SPEED REQUIREMENTS 




Speed = 741760^^^ X 48^^^ 

32 

= 1112.6 

KAPS 



plus 15% overhead 

166.9 

KAPS 



TOTAL REQUIREMENT 

1279.5 

KAPS 




(1) Two frames of 46,360 pixels at 8 bits per pixel. 

(2) Assuming two frames of pixels are processed each second. 

(3) Each 32 bit word processed is assumed equal to 48 equivalent add operations. 


Table 3. 4. 5-3 STATUS MONITOR 


STORAGE REQUIREMENTS 


DATA PROCESSING 


Functions 

Instructions 
(16 Bit) 

Data 

(32 Bit Wd) 

Total Storage 
(32 Bit Wd) 

Standard Linkage 

11 

18 

29 ' 

Retrieve Data from Auxiliary 
Storage Device 

12 

41875^^^ 

41887 

Locate Requested Parameters, 
Make Required Conversions on 
Both Scientific & Engr. Data 
and Provide all Required 
Preprocessing 

500 

(Same Core 
As Above) 

500 

Provide Software to Support 
Accessing Tolerance Limits 
via Keyboard 

200 

50 

250 

Compare S&E Parameters to 
Tolerance Limits 

32 

10 

42 

Preprocess Data for Display 

60 

20 

80 

Display Out-Of-Tolerance 
Parameters 

60 

30 

90 

standard Return Logic 

3 

0 

3 

TOTAL 

878 

42003 

42881 


SPEED REQUIREMENTS 


Speed 


1.34 X 10^ 

32 



plus 15% overhead 


TOTAL REQUIREMENT 


1340.0 KAPS 
201.0 KAPS 

1541.0 KAPS 


(1) Data retrieved and brought into approximately 165K core at 1/10 instrument 
output rate . 

(2) Processing 1/10 of a second's accumulated data every second, 

(3) Assuming 32 equivalent add operations for each 32 bit data word processed. 
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Table 3.4. 5-4 MONITOR AND DISPLAY FUNCTIONS 


STORAGE REQUIREMENTS 

DATA PROCESSING 


Functions 

Instructions 
(16 bit) 

Data 

(32 Bit Wd) 

Total Storage 
(32 Bit Wd) 

Standard Linkage 

11 

18 

29 

Retrieve Data from Auxiliary Storage 
D‘"i!Vice 

12 

41875^1 ^ 

41887 

Preprocess a "TBD" Sat of 
Parameters for Display (Involving 
Primarily Conversions and 
Calculations) 

500 

(Same Core 
As Above) 

'500 

Determine Data Generation Status 
for Data ACQ and Transmission 

100 

20 

120 

Provide Hardcopy and Printout of 
Data 

50 

10 

60 

Preprocess Data for Display 

60 

20 

80 

Display Data in Alphanumerical 
Format 

60 

30 

90 

Standard Return Logic 

3 

0 

3 

TOTAL 

796 

41973 

42769 


SPEED REQUIREMENTS 

s(l) (2) 

Speed - 1.34 X 10° X 32 - 1340.0 KAPS 

32 

plus 15% overhead = 201.0 KAPS 

TOTAL; REQUIREMENT . 1541.0 KAPS 


(1) Data fetched at 1/10 instrument output rate into approximately 165K of core. 

(2) Processing 1/10 of a second's accumulated data every second. 

(3) Assuming 32 equivalent add operations for each 32 bit data word. 
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3.4. 5. 5 Preprocessing Editing Software - The purpose of this technique 
is to identify invalid data and eliminate it from the data processing system 
at the earliest possible point, Checks will be made for all zeros, all ones, 
and other masks as identified by the experimenter. This function will be 
performed post real time at the convenience of the processing center. Table 
3.4,5-'5 sunwarizes the sizing requirements. 



Table 3.4. 5-5 PREPROCESSING EDITING SOFTWARE 


STORAGE REQIJ I REGENTS 


DATA PROCESSING 


Functions 

Instructions 
{16 Bit) 

Data 

(32 Bit Wd) 

Total Storage 
(32 Bit Wd) 

Standard Linkage 

11 

■ 18 

29 

Retrieve Data from Auxiliary 
Storage Device 

12 

41875^^^ 

41887 

Perform Reasonableness Type 
Tests on Data Against a Pre- 
Defined Mask Set by Principal 
Investigator 

40 

10 

50 

Output Acceptabl e Data onto 
a Tape (U.H.D.) 

12 

(Same Core As 
Large Block 
Above) 

12 

Standard Return Logic 

3 

0 

3 

TOTAL 

78 

41903 

41981 


SPEED REQUIREMENTS 



=(2) (3) 




_ 1.34 X 10° X 20 

Speed - 32 

= 

837.5 

KAPS 

plus 15% overhead 

= 

125.6 

KAPS 

TOTAL REQUIREMENT 


963.1 

KAPS 


(1) Data fetched at 1/10 instrument output rate Into approximately 165K 
of core. 

(2) Processing 1/10 ot a second's accumulated data every second. 

(3) Assuming 20 equivalent add operations for each 32 bit data word processed. 
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3.5 OPERATIONAL PROCEDURES 


Basically, operation of the SO-Ol-S interaction system will consist of 
monitoring sensor and software test outputs and reacting to control the 
mode of data collection/transmission. The monitoring function will be 
performed utilizing data and test results displayed at consoles located 
at the PSS (onboard) and at the POC (ground). The displayed results 
will then be used to assist in making decisions concerning experiment 
redirection and data flow mode control. Keyboard controls at the PSS 
and/or POG will direct the required signals to the onboard data command 
system. 

Two modes of operation will be defined for the SO-Ol-S interaction system; 
a "standard” mode for low activity periods and a "data" mode for periods 
of high solar activity. The interaction system operation may be initiated 
by the experimenter at any time after the occurrence of experiment activation 
at approximately ten hours after liftoff. Initially, the data mode for 
full data transmission should be selected in order to allow ground expertise 
a cursory look at data for an indication of acceptable systems performance. 

Once the experiment managers are confident of acceptable initial systems 
performance as indicated by the ground data monitor, the standard mode of 
interaction system operation will be initiated. 

The standard mode of system operation will involve routing the photoheliograph 
data to the loop recorder which serves as auxiliary storage for 15 minutes 
of recorded data. Once this recorder is filled with data, the tape is rewound 
and data overlay begins. During the playback of this recorder, data will be 
routed to the permanent recorder. The permanent recorder will also be 
used to store data during periods of TDRSS occultation. The data held on 
the permanent recorder will be downlinked at the earliest opportunity. The 
downlink control relay will be switched automatically to halt data transmission 
if software tests for sensor FOV occultation or excessive radiation levels 
dictate. Onboard standard operational procedures will include monitoring the 
outputs of other payload sensors for target of interest identification. 

Figure 3.3.1-1 presents an overview of this onboard interaction system. 
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standard ground operations will involve the processing of. previously 
collected data as desired by the experiment managers. This would include 
utilizing the facilities for solar flare detection, difference image , 
generation, and image comparison. Periodic transmission of a series of 
images will be required during the standard mode of operation to support 
these capabilities. Monitoring of the operational status console will 
be an ongoing feature of the ground operations, during both standard and 
high solar activity modes; If sensor or data system anomalies are detected, 
interaction system operation will be halted until the anomaly situation is 
resolved. Another pn-going ground interaction activity, which is performed 
off line, is the software editing of the collected data to eliminate various 
types of data known to be invalid. 

Whenever high solar activity periods are indicated by the various monitoring 
schemes which characterize the standard mode of operation or at the 
discretion of the experimenter, the data mode of full transmission may 
‘be selected. The mode selection may originate either onboard or from the 
ground. During this mode, the onboard recorders are off and the data is 
routed directly from the photoheliograph to the downlink. The data is 
collected by the ground system and held on high density tapes for subsequent 
processing. Once the solar activity diminishes to a level prescribed by 
the experiment manager, a return to the standard mode will be made. Commands 
for system mode control as well as those for on/off, power up/down, recorder 
playback, manual overrides for automatic elements, and control of the downlink 
relay may be initiated by either onboard or ground control. Table 3. 3. 1-2 
contains a summary of the data collect ion/ transmission management system. 

In summary, the interaction system is designed to provide tools to the 
experimenter with which he can status the experiment systems and identify 
targets of interest. This allows the experimenter to factor human judgment 
and expertise into the data flow management. He is further afforded tools 
for controlling the amount of data collected. In this manner, the quality 
and quantity of data collected is optimized by offering an alternative to 
continuous full data transmission. 
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3.6 COST/BENEFITS ANALYSIS 

To determine the net impact of implementing the interaction system for a 
SO-Oi-S payload mission, a cost versus benefits analysis was performed. 
Interaction system cost was determined by combining the costs of each indi- 
vidual hardv/are and software element of the system. Cost benefits were 
derived by estimating the cost savings incurred with the reduction* in the 
volume of data to be processed. These totals were then compared to generate 

a cost savings figure. 

Software elements of the interaction system were priced by estimating the 
development cost of each algorithm. The pricing assumed a cost of $20 
per instruction for both onboa'"d and ground based elements. This cost per 
instruction figure has been based upon Skylab and Saturn software development 
experience. Table'^3.6-1 presents a listing of individual algorithm costs. 

Hardware element costing assumed that standard laboratory equipment could 
be used. The only hardware element which would be situated in the space 
environment of the Spacelab pallet is the radiation detector and the space 
qualified feature would not significantly increase costs. Table 3.6-2 
summarizes the individual hardware element costs. Pricing the auxiliary 
recorder required projecting the technology since the data rate expected 
exceeds present recorder capabilities. However, such a recorder is presently 
under development by RCA Corporation for Goddard Space Flight Center. 

Table 3.6-2 HARDWARE COST ESTIMATES 


Downlink Control Switch $10,000 

Radiation Detector 10,000 

Auxiliary Storage 500,000 

TOTAL $520,000 
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Table 3.6-*l SOFTWARE COST ESTIMATES 


Interactive Techniques 

Instructions 

Cost ($) 

Navigation Scheme 

263 

5260.00 

Radiation Monitor 

201 

4020.00 

Loop Recorder Control 

484 

9680.00 

Sensor Monitor 

854 

17080.00 

Change Only Image Production 

794 

15880.00 

Data Recal 1 

288 

5760.00 

Status Monitor 

878 

17560.00 

Monitor and Display Functions 

796 

15920.00 

Preprocessing Editing Software 

78 , 

1560.00 

TOTAL 

4636 

92720.00 
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Cost benefits attributable to the interaction system are associated with 
a reduction in the data processing costs. These data volume reduction 
savings include areduction in computer processing, operations personnel, 
data storage, data turn-around, and data archiving costs. Of these 
savings areas, only computer processing and operations personnel costs are 
easily quantifiable. For the purposes of this study, only these two cost 
areas will be used to determine cost benefits. Table 3.6-3 indicates the 
data volume reductions estimated for each of the interaction elements for 

which this benefit is applicable. The figures shown in this table reflect 

percentages of the total volume of data expected in the absence of interaction 

12 

activities, i.e., 6‘X 10 bits. This volume reduction translates into 

4583 hours of computer processing time which, in turn, represents a cost 

savings of $1,245,000. These calculations assume 40 instructions per byte 

of data to be processed and an execution time of one microsecond per 

instruction. Comparison of this cost benefit figure, to the total cost 
of $612,720 for the interaction system yields a cost savings figure of 

$632,280. 


Table 3.6-3 DATA VOLUME REDUCTIONS 


Navigation Scheme 5% 

Radiation Monitor 5% 

Loop Recorder (flare only) 305S 

Status Monitor 5% 

Software Date Editing 1Q% 

TOTAL 55fo 


In summary, the proposed interaction scheme would result in a data processing 
cost savings of $632,280 for the first mission flown. Subsequent SO-Ol-S 
missions would share the system development cost responsibility and the more 
repeat missions flown, the greater would be the cost savings per mission. 

In addition to these cost savings, other data system benefits are a direct 
consequence of interaction system applications. Increased scientific value 
of the data can be realized from interaction system elements such as the 
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flare detection, difference image production and data recall algorithms. 

In particular, these elements can provide for more accurate target 
identification and. render the data more amenable to information extraction. 
In all cases, the total savings realized from the interaction system are a 
function of the Pis concern for data savings which will be reflected in 
system mode selection and also a function of the level of solar activity. 


4. E0-06-S INTERACTION SYSTEM 


4.1 INTRODUCTION- 

E0-06-S is a Spacelabi pallet only, payload. The payload flies only one 
sensor, a six spectral band Multi -Spectral Scanner (MSS). The MSS is an 
instrument capable of remotely sensing incident and radiated spectral 
information from a ground target as it is observed from the orbiting space- 
craft. At the present, all data gathered by the MSS is specified to be 
stored onboard the qrbiter via an Ultra-High Density (UHD) magnetic tape 
recorder supplied with the payload. MSS scientific data generation rate 
used in this study is 118.5 Mbps (this data rate has been obtained from MSS 
design and development community contacts), i.e. , for each of the six spectral 
bands it is 19.75 Mbps. The minimum scientific data generated in a seven day 
mission (31 data take passes x ,25 hr/data take pass) is calculated to be 
on the order of 3.35 x 10^^ bits and reasonably may be expected to exceed 
this with "target of opportunity" sightings, etc. 

Since no data is expected to be returned to ground except by the magnetic 
tapes returned at the end of each mission and since neither the payload nor 
the Command and Data Management Subsystem (CDMS) offer any more than a 
nominal evaluation capability of the collected data, a genuine need can be seen 
for some onboard analysis and evaluation tools capable of assuring confidence 
in the data quality and capable of assuring satisfaction of mission objectives 
in a timely manner. This assurance is realized through the means of the 
described interaction techniques which follow. The fact that CDMS in its 
very latest Configuration can not accommodate or provide these desired tools 
for this payload will also be discussed in the sections on Hardware/Software 
Requirements. 

The quantity of scientific data generated will be quantitatively reduced by 
the means of interaction to effect less storage requirements (both onboard and 
later in archival form), to effect less need for CPU facilities and time for 
data processing and to effect less need for manual analysis and evaluation 
time of the data for scientific value and content. The reduction of the data 
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by means of interaction is designed to maintain and improve data quality via 
the improved monitoring of the data collection system performance. Integrity 
of the scientific content or value of the data is maintained throughout 
the application of any interactive tool or technique. 

Interaction for E0-06-S may be generally understood to be implemented in 
the following manner: (1) By use of “screens" that will be applied to the 

data in real time (the particular screen or combination of screens to be 
applied will be determined by the experiment operator in light of the 
operational environment), and (2) by use of man-in-the-loop visual and 
judgmental faculties to qualify and further reduce the data quantity by 
resorting to visual scanning of the data and screening it for significance 
and quality after (1) above has been performed, i.e., a post-data pass 
screen is applied. 

This study bases its approaches and results on SSPD, Level B (June, 1974 as 
updated by contacts with the responsible design and development personnel 
assigned to E0-06-S), Spacelab Payload Accommodation Handbook (May 1975) and 
Spacelab Instrumentation Handbook (November 1974). The study assumes intent 
to integrate the E0-06-S payload with CDMS (see CDMS data in SO-Ol-S 
Introduction, Figure 3.1-1). Study output addresses the "delta" (addition 
or changes) to GDMS hardware/software capabilities as presently specified. 

Significant baseline data, in brief, for defining the E0-06-S Integrated 
Interaction System are; 

• MSS scientific data generation rate is 118.5 Mbit/sec or 19.75 
Mbit/sec for each of six spectral bands of output. 

• MSS Field of View (FOV) is 15°^ Instantaneous FOV (IFOV) is 

66 x 10"^ rad, with picture element resolution @ 12,5 meter 

(for 185 KM orbital altitude), 

• A picture element data word is represented as 8 bit coded gray 
scale. 
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0 S1x**band serial data @ ~ 120 Mbit/sec is stored directly (after 
multiplexing) on a Ultra-High Density (UHD) Magnetic Tape 
Recorder that is payload furnished. 

0 The UHD recorder has rewind and read capability. 

0 The MSS operation is controlled fully by the CDMS Experiment 
Computer Operating System (ECOS) via the Data Bus/RAU. The 
experiment computer maintains navigation and control information 
for gimbaling the MSS focal plane to correct for vehicle rate and 
control errors (no MSS independent gimbaling is possible). 

0 MSS operational status. Caution and Warning (C&W) information is 
available from the CDMS/ECOS, 

0 The CDMS Experiment Data Bus provides for high rate digital data 
(serial) transfer from the experiments with a limit of 500-600 
Kbit/sec (exclusive of analog data and discretes). The MSS Remote 
Acquisition Unit (RAU), however, is more severely limited by 
permitting fSlOO Kbit/sec of digital data. No other means of 
providing real time, high rate digital data from the experiment 
to the CDMS experiment computer is available. 

0 The CDMS/ECOS can control display of data (not scenes/images) 
provided to it via the RAU by the Integrated Interaction System. 
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4.2 INTEGRATED SYSTEMS DEFINITION 
4.2.1 Technique Evaluation 

The Phase II Spacelab User Interaction Study Report (May li)75) produced 
for E0-06-S some twelve techniques that had potential to interactively 
effect considerable data quality improvements and data quantity savings. 

The integration of these techniques into a single system with various 
operationally selectable modes of effecting interaction required an 
adjustment be made to some of the originally recommended techniques. The 
use of certain of the techniques became a matter of priorities centering 
around (1) value of reducing data quantity and enhancing data quality, 

(2) hardware/ software requirements and costs for Implementation and (3) 
practical consideration of difficulty to functionally build and use. The 
following paragraphs detail the disposition of those techniques. 

The Improved Payload Management in the Non-Visible Spectrums is supplied 
by the Real Time Display provided in each of the Real Time Screens that 
are functionally described in 4.2.2. Real Time Display of the Spectral 
Bands or Channels requires input/output processing and interim storage cap- 
abilities to condition the high rate scene data for video monitoring. The 
televised telescopic terrain view is not provided though it may be easily 
implemented if an Earth viewing telescope flies with the payload. 

The Processor for Use of Sampling Techniques is specifically applied to the 
very desirable goal of doing a brightness histogram or Spectral Condition 
Detection test on the MSS generated data in real time. The Spectral 
Condition Detection test is performed on only one channel of MSS data 
at any given time (see functional description Spectral Condition Detection) 

"Quick Looking" Data for System Performance is fully provided for as 
originally envisioned but is incorporated as a part of each real time 
screen and is selectable independently during the post data pass period 
of each orbit. 
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The System Anomaly Detection Processor is provid^id for by querying the 
CDMS experiment computer as to system C&W status. The response will 
determine the status of a data quality discrete indicator which may in 
certain instances terminate the data take, initiate self-test logic for 
fault location or just simply flag data as degraded (bad) in order to 
expedite ground processing. No provision is made to merge anomalous 
event data with the scientific data since little onboard image processing 
can be performed and with ground processing such data would be redundant 
to the telemetry which has already been downlinked, processed and is 
available. . _ 

The “Quick Look" Screen for the "Frame of Interest" is provided for in the 
Post Data Pass Screen (see Functional Description) though it is not implemented 
as originally conceived in Phase II. All benefits originally conceived for 
this technique are still realizable. The primary difference in the “Post 
Data Pass Screen" and the "Quick Look" for the "Frame of Interest" is that 
coding as to quality and utility of the screened data is performed rather 
than actuating a separate storage function for the resultant screened data. 

This approach precludes needs for simultaneously buffering six bands of scene 
data for storage on a secondary recorder, it precludes a second recorder 
{the onboard hi-data rate recorder would require a 6:1 ratio of record 
time to that of the MSS supplied recorder) and minimizes a highly probable wear 
out problem with MSS tape recorder start/ stop/ rewind functions. 

Post Pass Critical Analysis Screen for scientific content is available to 
the extent that onboard CDMS computational and analytical tools can be 
called up to critique a given scene. No onboard full image processing 
and data analysis is reasonably possible using CDMS because of the 
RAU/Data Bus rate limitations and the limited core (which affects time to 
process a given scene) available in the CDMS. 

The technique, A Screen to Record Only When Condition Requirements are Met, 
is implemented by the real time screen (see Functional Description), Spectral 
Condition Detection. However, the continuous monitor (or detector) for the 
given spectral condition can evaluate only one spectral channel to any given 



time to determine data acceptability. The technique used does not rely on 
the continuous loop recorder or separately starting/stopping the final 
storage recorder; rather the Spectral Condition Detection screen simply 
annotates the data in real time, on a once per second basis, as to data quality 
and utility which can accomplish all of the originally intended benefits. 

Ground Beacon Control of the Data Take is implemented as described in the 
Phase II study output. 

The Processor for Automated Data Take is implemented as described in the 
Phase II study output with the additional refinement of preparing the system 
in advance for the data take. Provision is also made for tape recorder OFF at 
occasions where MSS Shutdown and Warmup periods overlap for targets in near 
proximity (timewise) of each other but the data record operation is not continuous. 

f 

Provision for Onboard Analytical Tools is implemented by the provision within 
each real time, automated screen application and the post data pass screen 
to access computational and plot capability via display keyboard controls. 

Plot application programs will utilize the onboard CRTs for display. This 
•approach saves the need for a desk calculator with the typically available 
peripherals. Plot programming is intended to be generalized and simple 
where data points are keyboard entered or accessed from tape and where 
y = f{x); f(x) is some polynomial expression Xa^^X''*. Coordinate scaling 
would, be specified. 

Onboard Correction of Detected Roise is not provided due to the hardware/' 
software complexity and CPU size required for onboard implementation as an 
independent, automated screen. However, most of the desired benefits are dis- 
tinctly realizable from the image quality of scene displays (in real time or 
post data pass) already provided with each of the screens from the integrated 
systems. More elaborate analysis, if ever required, can be provided in 
real time via TDRSS network link by downlinking any of the six available 
MSS spectral bands (max @ 20 Mbps) for the brute force evaluation required in 
a fourier frequency analysis scheme. 
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The "Sub-Area" Screen for "Frame of Interest" is not implemented for this 
payload. This screen still appears to be of considerable value when not 
restrained by the two difficulties apparent in this payload. The "Sub-Area" 
Screen for "Frame of Interest" is dependent on a buffer capable of holding 
a full data frame (~ 100 Mbits of data) for one channel and being able to, 
in effect, start/stop/ rewind and address the same frame on other tape 
channels (or buffer up to ~ 600 Mbits of data and address up to all six 
spectral bands simultaneously) hundreds of times per data tape (state of 
the art reliability forecasts will not permit this at the present). The 
other aspect of this technique is that a frame (~ 5 sec of data) typically 
represents an area computed to be « 40 mi. x 25 mi. It is doubtful that 
time and skills will permit sufficient sub-sectioning of a frame and still 
assure enough recognizable, well -referenced Ground Control Points (GCPs) 
to geometrically, etc. correct the small sub-section that might be stored, 

4.2.2 Functional Description 

Real Time Screens: 

• Spectral Condition Detection - This screen when selected by 

the experiment operator, will perform automatically as a continuous 
monitor of the MSS data as it is being generated. The screen 
is applied to only one spectral band of data. The channel is 
selected in advance of flight as a true indicator of desirable 
or undesirable spectral characteristics that the experimenter 
desires to screen all MSS data against. One second's worth 
(~ 20 Mbits) of digitized pixel data representing a scene is 
evaluated by the screen each second of data generation. Each 
second of data generated and stored on the UHD magnetic tape is 
annotated by code (Pass or Fail /Good or Bad) as to whether or not 
it satisfied the spectral quality density test criteria and 
acceptable data system C&W conditions. The spectral density 
test provides for rapid post data pass screening and sorting of 
all collected data and also provides an expedient means to 
more rapidly create computer compatible data tapes (CDTs) 


during ground processing. Simultaneous to the application of 
this screen any one of the six spectral bands may be selected at 
any time for display to examine and visually monitor on a more 
or less continuing basis the performance of the data collection 
system for that spectral band. Certain system malfunctions 
and/or sufficient data degradation provides for timely termination 
of a bad data take. 

• Ground Beacon Control - This screen when selected by the experiment 
operator performs in response to recognition of a ground signal as 
it is transmitted from the vicinity of the target that is to be 
observed. The signal will be directional requiring sensor l.s! ing 
of the target before data recording operations can commence. 

When the signal ceases transmission or sighting of the target 
cannot be maintained, the data record activities will cease. 
Simultaneous to the application of this screen any one of the 
six spectral bands may be selected fpr display to examine and 
visually monitor on a more or less continuing basis the performance 
of the data collection system for that spectral band. Certain 
system malfunctions and/or sufficient data degradations may 
provide for timely termination of a bad data take by the experiment 
operator. 

• Fully Automated Data Take Controls This screen makes use of onboard 
navigation and control parameters that are available from the CDMS 
experiment computer. When this screen is selected by the experiment 
operator, these available navigation and control parameters will 

be utilized to reckon ground track in an as exact a manner as 
possible. Resultant ground track positional computations will be 
used to reckon desired target(s) proximity. When the ground track 
computations indicate a radial proximity, XI (value is TBD), to 
the desired target data take READY operations are performed and 
when ground track computations indicate a radial proximity, X2 
(Xg < Xj^ Xg value is TBD), to the desired target date take RECORD 
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operations begin. When ground track computations .indicate a 
departure from the desired target beyond the radial proximity 
of X2 data- take RECORD operations cease and the data collection 
system may be placed in a READY or OFF category of operation 
dependent upon proximity to the next scheduled target. Desired 
targets (say, for a 72 hour period, i.e., 15-20 targets) with 
respective ground track coordinates will be RF linked to the CDMS 
computer from mission control. The CDMS computer will maintain a 
record of targets sighted and will provide a list of targets not 
visible (obstructed viewing-clouds, haze, night, etc.) or not 
acquirable (due to system malfunction, C&W indications, etc.). 
Unacquired or non-visible targets are to be considered for possible 
rescheduling. With the application of this screen, any one of 
the six spectral bands may be selected for display to examine and 
visually monitor, on a more or less continuous basis, the performance 
of the data collection system for that spectral band. Certain 
system malfunctions and/or sufficient data degradations may provide 
for timely termination of a bad data take by the experiment operator. 

• Real Time "Quick Look” for MSS Performance - This screen, though 
selectable, in effect, while operating in any of the automated 
modes of real time screening of data is also selectable when all 
data collected is being stored on UHD magnetic tape and no other 
screens are in effect. Real time, quick looking of MSS data 
permits a timely scan of data collection system performance on a 
per channel basis. This is provided for by a manual selection of 
■ the desired MSS spectral band/channel to be scanned and subsequently 
displaying the scene data generated by that channel. Quick ok 
scanning of the scene data in this manner will permit the experiment 
operator to make the earliest possible evaluation and corrections 
if necessary to the data collection effort. Display resolution 
limits permit a horizontal and vertical sampling of data to be 
performed that facilitates the Implementation of the display 
requirements. 
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Post Data Pass Screen - The data stored on the UHD. magnetic 
tape which has been previously subjected to the real time screens 
will be further examined during the post data pass portion of the 
orbits. This technique will make a more efficient use of the 
hardware and software already provided for by the Real Time 
Interactive Display capability. The stored data will be reviewed 
and examined as required to provide reasonable and final assurance 
of the quality and significance of the immediately past data 
collection efforts. Data display rate is an option of the data 
evaluator. This technique provides a timely means to assess and 
take remedial action for bad data taken or to capture additional data 
on a target or scene of previously unsuspected scientific value. 


4.3 HARDWARE SPECIFICATIONS 
4.3,1 Introduction 

The groundrule for integration of the proposed MSS interaction techniques 
into the CDMS was to make maximum use of the standard CDMS components. 

However, speed limitations of these components when compared to the high 
data rate of the MSS, precluded their use for analysis or display of the 
scientific data being generated. Special purpose components are specified 
to provide the capability to handle the real-time scientific data stream. 

The technology for these components is 1980 technology, although 1980 
state-of-the-art hardware has been avoided where possible. That is, the 
system design has been molded to fit reasonable operational specifications 
for the hardware, if state-of-the-art operation was not demanded. 

Assumptions and definitions used in the development of the hardware configurati 
are listed below: 

{1} Bata should be tagged as good or bad in approximately one second 

intervals on the tape recorder. This technique is used to identify 
data that has been determined not to meet the spectral requirements 
of the data tape. Ideally, this data would be eliminated from the 
data recorded for later ground processing, but the extremely high 
data rate of the instrument, 118.5 Mbits, imposes too strenuous a 
requirement on data collection, interim storage, and subsequent 
recording to permit deletion of data. Instead, all data is recorded 
and tagged; ground processing of the unsuitable data can then be 
eliminated, based on the data "quality" tag. Implementation of the 
one second criteria is probably best mechanized in terms of 
approximately one second’s worth of instrument scan lines, instead 
of on a strict time basis. 

(2) Data is generated by the MSS in a 4000 pixel per Tine resolution. The 
scan rate is adjusted to give approximately the same “vertical" 
resolution. For video display, sampling of the data to produce a 


666 pixel per scan, 525 line image, will produce an acceptable image. 
This resolution results from a 1:6 data sample for each line, and 
selection of one out of six scans. The selection process has been 
designed to produce a video display with approximately the same 
resolution as commercial television, while reducing the data rate to 
a range manageable with computers. 

Video images are required in all six spectral bands produced by 
the MSS. Only one band at a time is utilized to produce an image; 
therefore, a channel selector must be provided to select the band 
desired for the video display. 

Spectral density and quality analysis can be performed using a single 
MSS band. This band has arbitrarily been designated as vl in this 
section. 

Use of the CDMS computer for the spectral density and quality analysis 
would require sampling channel #1 at a 1:200 rate to slow the data 
down to within the computer processing capability, The analysis 
“granularity" produced by this sampling rate is not acceptable for 
ori“board, real-time, interaction and dictates the addition of a 
separate MEDI computer (medium size dedicated processor) for this 
function. Sampling of channel #1 can be performed at a 1:10 rate 
utilizing a 1980 MEDI computer, a 20 to 1 improvement over the CDMS 
computer. 

Real-time displays of spectral density and quality analysis are 
required. This function has been allocated to the CDMS computer. In 
addition, the Cit^MS computer has bean allocated Caution and Warning 
activity for the payload, image motion compensation computations and 
control and automation of all instrument control functions assignable 
to the CDMS. Instrument design has not progressed to the point 


where automated features can be identified. As a minimum, power 
control to the scan mechanism and instrument would be expected, with 
possible additions of thermal control, internal redundancy control, 
filter selection (polarizing, neutral, clear, etc.) and other as yet 
undefined operational features might be added. The standard CDMS 
hardware (computer, data bus, RAU, display system) will be utilized 
for instrument automation. 

(7) Post-data-pass analysis of collected data is required to review the 
suitability of the data for its intended use. 

(8) Auxiliary memory will be provided by a developing technology. The 
requirement exists in this application for a fast, large, easily 
accessible memory for interim storage of the scientific data prior 
to spectral density/quality analysis and video display. Bubble 
and CCD technologies are candidates for this storage medium. 

4,3.2 Hardware Descriptions and Specifications 

Figure 4.3-1 illustrates the hardware required for the implementation of 
EO-06-S interactive techniques. Interfaces to the standard CDMS components, 
and to the payload components are indicated. Although the actual MSS data 
rate is 118,5 Mbits, 120 Mbits has been used throughout the hardware analysis 
for convenience. Thus, an individual channel data rate is listed at 20 
Mbits instead of 19.75 Mbits, 

Table 4.3-1 lists the major hardware items which must be supplied in addition 
to the standard CDMS equipment. Signal interfaces, brief descriptions, and 
applications of the six equipment items are listed. Further descriptions 
of the equipment are provided in the following paragraphs: 

Microprocessor #1 - Figure 4,3-2 illustrates the functions that must be 
performed in microprocessor Real-time data generated by the MSS is 
stored by this computer into the auxiliary memory. Channel #1 of the MSS, 


4-13 




FIUTERED VEHICLE RATES 




L_1 ' , ! 


1 RAU 

_ 1 MBPS data BUS 

COMS 

COMPUTER 

• caw 

• IMAGE MOTION I 

COMPENSATION , 

o INSTRUMENT 
CONTROL 

• DISPLAY OF 

n 

LJ 

di/do 


HI 


LEGEND 

STANDARD CD MS 
COMPONENTS 


PAYLOAD COMPONENTS 


0.1 MBPS 




20 MBITS 


SYNC 



MICRO 


PROCESSOR 


N0.1 

lOP » 

• REAL-TIME 


DATA 


STORAGE 


AUSilLIAHY 
STORAGE 
1.5 MBIT 


AUXILIARY 
STORAGE 
S.D MBIT 


MED) COMPUTER 


• THRESHOLD 


CALCULATIONS 


• SPECTRAL 


CONDITIONING 


ACCEPTANCE 

lOP 

TEST 


• caw STATUS! NG 


• DISPLAY OUTPUT 


PROCESSING 



GOOD/BAD 
DATA STATUS 


SPACE LAB DISPLAY- 
SYSTEM 


MICRO 
PROCESSOR 
NO. 2 

• VIDEO GEN 


lOP 


VIDEO • 
MONITOR 


Figure 4.3-1 E0-06-S IHTERACTIO.J HARDWARE; OVERALL BLOCK DIAGRAM 


VIDEO 

















Table 4.3-1 EO-06 

Item 

Microprocessor #1 
Microprocessor #2 

Medi Computer 
Multiplexer 


Channel Selector 
Auxiliary Storage 


S MAJOR INTERACTION HARDWARE 


Application 
Real-time data storage 


Video display generator 


Spectral density and 
quality analysis, 
display support 


Combines MSS channel 
outputs and good/bad 
data status into a 
serial data stream 
compatible with tape 
recordt.r input 

Selects desired input 
(1 of 6 MSS channels 
or recorded data) for 
processing 

Temporary storage of 
real-time scientific 
data for onboard 
processing 


Description 

10 usee cycle time, IK working memory; 

2 high speed (20 MBIT) input data 
channels; 2 high speed data output 
channels 

2 usee cycle time; IK bytes working 
memory; 1 high speed input data channel; 
multiple D/A converters, synchronization 
generator EIA standard RS170 video 
output 

500 nsec cycle time; 16K bytes working 
memory; serial output channel; one 8-bit 
parallel output channel; one 8-bit 
parallel input channel 

Six 20-MBIT serial data inputs; 1-slow 
speed serial data input; one 120-MBIT 
serial data output 


Six 20-MBIT serial data inputs; one tape 
recorder input; one 3-bit channel 
selection input; one 20-MBIT serial data 
input 

7.5 MBIT total storage; two 80-bit parallel 
data inputs; one 160-bit parallel data 
output; one 16-bit parallel data output 


Signal Interfaces 

MSS, channel selector 
auxiliary memory 


Auxiliary memory, CRT 


Auxiliary memory; 
mulriplexer; RAU 


MSS, Medi Computer, 
tape recorder 


MSS, tape recorder, 
microprocessor #1, 
RAU 


Microprocessor #1, 
microprocessor #2, 
Medi computer 
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a 20 Mbit serial data stream, is used for spectral density- and quality 
calculations. The lOP portion of microprocessor #1 converts this serial 
data stream to a 160 bit parallel format, of which 8 bits are stripped 
out and the rest discarded. These 8 bits represent one pixel of data and 
will be obtained each 8 microseconds. 

Ten pixels are accumulated in the stacker before being stored in the auxiliary 
storage. Address control fs supplied by the CPU to route the data into 
the proper location in memory. 

Two developing memory technologies, CCDs and bubble memories, are particularly 
suitable to parallel input data formats; however, monolithic or core 
memories could also be organized for parallel data inputs. 

The serial data stream selected by the channel selector for display to 
the onboard payload specialist is applied to a similar set of lOP hardware 
as was described above. Initial serial to parallel conversion in this case 

is selected to be 48 bits, 6 pixels. Eight of these bits are stripped 
out and applied to a stacker each 2.4 microseconds, the remaining bits 
are discarded. The stacker accumulates 80 bits in 24 microseconds, and 
under CPU control, stores them away in auxiliary storage. Synchronization 
with the instrument is required to permit organized storage of the serial 
data stream by lines and frames. 

Microprocessor #2 - A functional description of microprocessor #2 is 
illustrated in figure 4.3-3. Data stored in auxiliary storage by micro- 
processor is extracted and processed to form a video signal for display. 
Data extraction in 160 bit {20 pixel) blocks each 2 microseconds will 

permit CPU functions of organization and data routing to be accomplished 
with realizable CPU speeds. Four functions are required of the CPU 
processing: 

(1) Data must be sorted into lines and frames according to a 
predetermined pattern in auxiliary storage. 
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( 2 ) 


Every other line must be reversed since the scanning action of 
the MSS is alternately left-to-right and right-to-left. While 
the video display is always left-to-right. 

(3} Interlacing of the video is required for display; this function can 
logically be combined with scan reversing. Thus the first half- 
frame will be "unreversed" data followed by a second half-frame of 
reversed data interleaved line for line with the first half-frame. 

(4) Sync must be generated for insertion onto the video stream. 

Multiple D/A converters will be required to create a video luminance signal 
from the digital data stream. Since data is being moved to 20 pixel 
blocks* a group of 20 converters would allow simultaneous loading for 
conversion. Since an essentially continuous data stream is required, a 
second set of 20 converters would allow the conversion process and setting 
of the outputs to occur in one set {during a two microsecond time period) 
while the outputs of the second set are being gated onto the video stream. 

The sync signal must be summed with the luminance signal to produce the 
video for display. 

MEDI Computer - Scientific data processing and display functions will be 
performed by the MEDI computer, Figure 4.3-4. Data from channel #1 of the 
MSS is stored into auxiliary memory by minicomputer #1; retrieval of the 
stored data and processing to determine acceptability for its intended 
scientific use is performed by this medium size computer. Communication to the 
onboard payload specialist through CDMS components (RAU, computer, display) 
will provide the means for human interaction. Sizing of the software load 
indicates a high-speed CPU will be required, one with an equivalent add time 
of less than 500 nsec. Although this represents an extremely fast capability, 
1980 technology is expected to be able to provide this capability without 
severe cost penalty. 
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CDMS display capability is provided by 8 bit parallel paths Into and out 
of the medi computer., A serial data path to the multiplexer will produce 
the good/bad indication to be recorded following each one second (approximately) 
block of data being analyzed. 

Multiplexer - The high speed tape recorder being developed by GSFC is 
the only recorder available for data recording from high speed instruments 
such as the MSS. This recorder accepts a 120 Mbit serial data stream 
for recording. Since the MSS output consists of six 20 Mbit streams plus 
the good/bad data status signal, an incompatibility exists. The payload 
design must supply a multiplexer to produce a 120 Mbit data stream from the 
six 20 Mbit streams. The interaction system's good/bad status signal, if 
accommodated into the original multiplexer design,, would be little or no 
impact on the cost of this item since the data rate involved is so low. The 
method and format of the good/bad indication has not been selected at this 
time, 

Channel Selector - The channel selector (figure 4.3-1) performs two functions: 

c Selection of one of the six 20 Mbit MSS output channels for 
video generation 

t Creation of a microprocessor compatible signal from the tape 
recorder during data playback 

Mechanization of the first function is straightforward and requires svtt'aching 
of one of the MSS outputs to microprocessor #1. Three discrete outputs from 
the RAD will perform the switching in response to a CDMS display system 
(keyboard) input. 
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Tape recorder signal handling at present represents an unknown addition 
to the channel selection capability, since the recorder output format 
is undefined. At best, a single channel will be available from the tape 
recorder and can be switch selected using the same three RAU discrete 
outputs utilized for MSS channel selection; at worst, a single channel will 
have to be demultiplexed from the total tape recorder output. 

Auxiliary storage - A total of 7,5 Mbits of auxiliary storage is required 
for the interaction procedures defined for E0-06-S, This storage falls 
into two separate categories (figure 4.3-1). Storage for data quality 
processing will require approximately 1.5 Mbits, 1 Mbit for data storage 
and 0.5 Mbit for miscellaneous working code and growth. Video generation 
memory has been sized at 6.0 Mbits. Of this amount, 5.5 Mbits is required 
for storage of two "frames" of video data. This allows data for one image 
to be used for image refreshing while the second image is being "built" 
from the real-time data stream. As before, 0.5 Mbits is defined for working 
memory and growth. 

'A discussion of memory technologies applicable for this storage is provided 
under the SO-Ol-S hardware section. 
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4.4 SOFTWARE REQUIREMENTS 

4.4.1 Introduction 

This sizing activity was concerned with establishing onboard sizing require- 
ments for the proposed E0-06-S interactive techniques. As with the sizing 
requirements for the SO-Ol-S payload, estimates are given in terms of computer 
memory capacity and processor speed. Table 4.4-1 summarizes the results 
of this effort. Subsection 4.4.3 provides the detailed breakdown of the 
onboard processing functions for each individual technique. 

Every effort was made to "delta" the E0-06-S onboard interaction requirements 
from the existing CDMS; however, due to the large data rates, it was 
necessary to sample the data and assume that additional computer support 
would be available. This additional support is explained in the previous 
"Hardware Specification” section (see Figures 4.3-1 thru 4.3-4). 

4.4.2 Assumptions and Sroundrules 

The same basic assumptions and estimation procedures used for i;jie SO-Ol-S 
payload apply to the techniques proposed for E0-06-S. In summary these 
are: 

» Utilization of the general purpose CDMS computer whose operands 
are 8, 16 and 32 bits for fixed point operations and 32 bits for 
floating point. 

• Each technique is represented as an independent subroutine, 
called by an executive under Spacelab executive control. 

• Navigation and attitude data is provided to the payload by 
the PAC subsystem which is updated from the orbiter. 
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Table 4.4-1 E0-06-S SOFTWARE SIZING REQUIREMENTS 



Techniques 

Total Storage 
(32 Bit Words) 

Processor Speed 
Data Processing 
(KAPS) 

Processor Speed 
Control & Monitoring 
’(KAPS) 

Spectral Condition Detection 

4364 

2300 

0.398 

Ground Beacon Control 

4063 

1150 

0.518 

Fully Automated Data 
Take Controls 

4236 

1725 

0.555 

Real Time “Quick Look" of 
Unscreened Channel Performance 

3800 

1150 

ii/A 


• Total storage Is determined by adding half of the number 
(3f Instructions to the nMinber of data words. 

(i 

• Processor speed for control and monitoring functions is 
determined by letting one instruction equal 1,5 equivalent 
add operations. 

• Speed requirements for scientific data processing are determined 
as the number of instructions required to process logical blocks 
of code in equivalent add operations. For data processing 
functions concerning just simple tests and tape generation, 

16 equivalent adds per 16 bit data word are assumed. 

• A 15% data processing overhead rate is used. 

4.4.3 Computer Sizing Analysis 

4.4.3. 1 Spectral Condition Detection - This interactive technique was 
proposed to determine the spectral quality for a scene of digitized data. 
Spectral quality and density checks involve processing the image data for 
video and alphanumeric display, making pixel threshold calculations, and 
recording quality status of the data on ultra-high density tapes for later 
analysis. This technique will be selected by the experimenter, and v/ill 
operate continuously until deactivation or end of experimental period. 
Table 4.4. 3-1 summarizes the sizing analysis for both storage and speed 
requirements. 
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Table 4.4. 3-1 SPECTRAL CONDITION DETECTION 

■ STORAGE REQUIREMENTS 

DATA PROCESSING ' 


Functions 

Instructions 
(16 Bit) 

Data , 

(32 Bit Wd) 

Total Storage 
(32 Bit Wd) 

Standard Linkage 

24 

20 

32 

Prep and Route Data to 120 
MBPS Tape 

40 

10 

30 

Prep Data for 1.5 Mbit Auxiliary 
Storage 

20 

10 

20 

Prep Data for 6.0 Mbit Auxiliary 
Storage 

30 

10 

25 

Access 1.5 Mbit Auxiliary Storage 
with MEDI Computer 

20 

3200* 

3210 

Perform Pixel Threshold Calc. 

32 

6 

22 

Perform Spectral Conditioning 
Calculations 

10 

2 

7 

Preprocess Data for Displaying 

60 

20 

50 

Evaluate C&W Status 

50 

10 

35 

Write Data Acceptance Code 
on Tape 

20 

4 

14 

Transmit Data to lOP D — ►A 
Converter, Process, Sync, 
Interlace & Display Video Images 

150 

256 

331 

Transmit Data via RAU to CDMS 
Computer and Display Alpha- 
numeric Data 

60 

30 

60 

Provide Plot Capability on 
Image Data 

400 

120 

320 

Standard Return Logic 

20 

0 

10 

SUBTOTAL 

936 

3698 

4166 


*Approx1mately 10 fetches per second assuming MED! computer has 16 K of memory. 
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Table 4. 4. 3-1 SPECTRAL CONDITION DETECTION (Continued) 
CONTROL AND MONITORING (ORB ITER COMMUNICATIONS) 


Functions 

Instruct! onL 
(16 Bit) 

Data 

(32 Bit Wd) 

Total Storage 
(32 Bit Wd) 

Provide Caution and Warning 
Software Interface 

20 

5 

15 

Perform Image Motion 
Compensation 

150 

50 

125 

Assure Instrumentation Control 

75 

0 

38 

Provide Filtered Vehicle Rates 
and Attitudes 

20 

10 

20 

SUBTOTAL 

265 

65 

198 

TOTAL 

1201 

3763 

4364 


SPEED REQUIREMENTS 
DATA PROCESSING (1) 

Speed = « 2000 KAPS 

plus 15% overhead 300 KAPS 

TOTAL REQUIREMENT 2300 KAPS 

(1) Assumingg32 equivalent add operations per 16 bit data word in processing 
1.0 X 10° bits per second. 

CONTROL AND MONITORING 

Speed = 265 X 1.5 0.398 KAPS 
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4. 4. 3. 2 Ground Beacon Control - This technique will be selected by the 
experimenter to sense data upon response from a ground transmitted signal. 

This signal will emanate from the vicinity of the desired target. Data 
will be recorded only when the signal is received or the target is within 
the field-of-view of the sensor. During periods when the signal is either 
not transmitted or sighting of the target cannot be maintained, the data 
recording operation is halted. The sizing requirements for this technique 
are given in Table 4.4. 3-2.. 

4. 4. 3. 3 Fully Automated Data Take Controls - The purpose of this technique 
is to automatically gather data for a selected set of targets. Onboard 
navigation and control parameters v/ill be obtained from the CDMS computer. 
Selected targets will be scheduled with sufficient lead-time to permit 
instrumentation warm-up and calibration. In the event that data gathering 
from scheduled targets is not possible, the CDMS will maintain a record of 
the targets and reschedule them at some later point in time. All data 
‘gathered in this automatic mode will be recorded on an ultra-high density 
tape. Data gathering may be scheduled in advance for up to 72 hours for 

an estimated 15 to 20 targets at approximately 15 seconds per target. 

Table 4. 4.3-3 shows the sizing requirements for this technique. 

4.4. 3.4 Real Time "Quick Look" of Unscreened Channel Performance - This 
technique provides a timely scan of how well the system is performing by 
displaying scenes transmitted on manually selected channels. This "Quick 
Look" approach will enable the experimenter to make the eatUest possible 
corrections to the data acquisition devices and/or preliminary processing 
algorithms. Display resolution is sufficient for evaluating system performance 
in this manner. The computer sizing requirements for this technique are 
presented in Table 4. 4.3-4. 

4.4. 3. 5 Post Data Pass - This technique will enable the experimenter to 
perform a detailed evaluation of the data that was recorded on the ultra- 
high density tape during the real time processing. Post-processing associated 


Table 4.4. 3-2 GROUND BEACON CONTROL 

STORAGE REQUIREMENTS 


DATA PROCESSING 

Instructions 

Data 

' Total Storage 

Functions 

(16 Bit) 

(32 Bit Wd) 

(32 Bit Wd) 

Standard Linkage 

24 

20 

32 

Set Up to Begin Data Collection 

12 

6 

12 

Check Experimert Operational 
Status 

6 

2 

5 

Prep and Route Data to 120 MBPS 
UHD Tape 

40 

10 

30 

Check Target Alignment 

40 

10 

30 

Check If Display Required 

6 

2 

5 

Prep Data for 1.5 Mbit Auxiliary 
Storage 

20 

10 

20 

Prep Data for 6.0 Mbit Auxiliary 
Storage 

30 

10 

25 

Access 1.5 Mbit Auxiliary storage 
with MEDI Computer 

20 

3200* 

3210 

Prep Data for Display 

60 

20 

50 

Transmit Data to lOP D’ — *-A 
Converter, Process, Sync, 
Interlace & Display Video Data 

150 

256 

331 

Transmit Data via RAU to CDMS 
Computer and Display Alphanumeric 
Data 

60 

30 

60 

Standard Return Logic 

20 

0 

10 

SUBTOTAL 

488 

3576 

3820 


*Approxitnately 10 fetchps per second assuming MEDI Computer has 16K of memory. 
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Table 4. 4.3-2 GROUND BEACON CONTROL {Coircinued) 


CONTROL AND MONITORING (ORB ITER COMMUNICATIONS) 


Functions 

Instructions 
(16 Bit) 

Data 

(32 Bit Wd) 

Total Storage 
(32 Bit Wd) 

Perform Image Motion Compensation 

250 

60 

185 

Assure Instrumentation Control 

75 

0 

38 

Provide If Required,* Filtered 
Vehicle Rates and Attitudes 

20 

10 

20 

SUBTOTAL 

345 

70 

243 

TOTAL 

833 

3646 

4063 


SPEED REQUIREMENTS 


DATA PROCESSING 

Speed = 3_000 KAPS 

plus 15% overhead 150 KAPS 

TOTAL REQUIREMENT 1150 KAPS 

(1) Assum1nggl6 equivalent add operations per 16 bit data word in processing 
1.0 X 10° bits per second. 

CONTROL AND MONITORING 

Speed =345 x 1,5 = 0.518 KAPS 
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with this technique involves making calculations and displaying the alpha- 
numeric data on a CRT. If necessary, and at the experimenter's option, 
the calculations and displayed quantities should be updatable in an 
interactive fashion. Table 4. 4. 3-5 depicts the sizing requirements for 
the "post data pass" processing. 


Table 4.4. 3-3 FULLY AUTOMATED DATA TAKE CONTROLS 


STORAGE REQUIREMENTS. 

DATA PROCESSING ' . 


Functions 

Instructions 
(16 .Bit) 

Data 

(32 Bit Wd) 

Total Storage 
(32 Bit Wd) 

Standard Linkage 

24 

20 

32 ■ 

Access and Process Vehicle 
Orbital Position and Uplinked 
Ground Target Coordinate 
Information 

20 

6 

16 

Schedule Upcoming. Target 

150 

30 

105 

Assure Vehicle to Target 
Proximity 

40 

10 

30 

Maintain Target Track Log 

30 

5 

20 

Set Up to Begin Data Collection 

12 

6 

12 

Prep and Route Data to 120 MBPS 
UHD Tape 

40 

10 

30 

Check if Display Required 

6 

2 

5* 

Check to See if Schedule Permits 
Powering Down Certain 
Equipment (Tapes, etc.) 

20 

5 

15 

Prep Data for 1.5 Mbit Auxiliary 
Storage 

20 

10 

20 

Prep Data for 6.0 Mbit Auxiliary 
Storage 

30 

10 

25 

Access 1.5 Mbit Auxiliary Storage 
With MEDI Computer 

20 

3200* 

3210 

Prep Data for Display 

60 

20 

50 

Transmit Data to lOP D — >-A 
Converter, Process, Sync, 
Interlace & Display Video Data 

150 

256 

331 

Transmit Data via RAU to CDMS 
Computer and Display Alpha- 
numeric Data 

60 

30 

60 

Standard Return Logic 

20 

0 

10 

SUBTOTAL 

702 

3620 

3971 


*Approxiinately 10 fetches per second. 
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Table 4. 4.3-3 FULLY AUTOMATED DATA TAKE CONTROLS {Continued) 


^ ■ t 

CONTROL AND MONITORING (ORBITER COMMUNICATIONS) 


Functions 

Instructions 
(16 Bit) 

Data 

(32 Bit Wd) 

Total Storage 
(32 Bit Wd) 

Perform Image Motion 

Compensation 

300 

50 

200 

Assure Instrumentation Control 

50 

20 

45 

Provide Filtered Vehicle Rates 
and Attitude as well as 
Navigation Inputs 

20 

10 

20 

SUBTOTAL 

370 

80 

265 

TOTAL 

1072 

3700 

4236 


SPEED REQUIREMENTS 

« 1500 KAPS 

225 KAPS 
1725 KAPS 

(1) Assuming 24 equivalent add operations for each 16 bit data word in 
processing 1.0 x 10^ bits per second. 

CONTROL AND MONITORING 

Speed = 370 x 1.5 = 0.555 KAPS 


DATA PROCESSING 


Speed 


1.0 X 10® X 24 


( 1 ) 


16 


plus 15 % overhead 
TOTAL REQUIREMENT 
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Table 4. 4. 3-4 REAL TIME "QUICK LOOK" OF UNSCREENED CHANNEL PERFORMANCE 


STORAGE REQUIREMENT!^ i 


DATA PROCESSING 


Functions 

Instructions 
(16 Bit) 

Data 

(32 Bit Wd) 

Total Storage 
(32 Bit Wd) 

Standard Linkage 

24 

20 

32 

Select Channel of Interest 

10 

2 

7 

Set Up te Begin Data Collection 
for Selected Channel 

12 

6 

12 

Buffer Data for Single 20 MBPS 
Channel Using Micro-Processor 
#1 into Both 1.5 & 6.0 Mbit 
Auxiliary storage Areas 

50 

20 

45 

Access 1.5 Mbit Auxiliary Storage 
with MEDI Computer 

20 

3200* 

3210 

Prep Data for Display 

60 

20 

50 

Transmit Data to lOP D— *"A 
Converter, Process, Sync, 
Interlace and Display Video Data 

150 

256 

331 

Transmit Data via RAU to CDMS 
Computer and Display Alpha- 
numeric Data 

60 . 

30 

60 

Check to See if Processing is 
Complete 

6 

2 

5 

Standard Return logic 

20 

0 

10 

SUBTOTAL 

412 

3556 

3762 


*Approximately 10 fetches per second. 
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Table 4. 4. 3-4 REAL TIME "QUICK LOOK" OF UNSCREENED CHANNEL PERFORMANCE 
(Continued) 


CONTROL AND MONITORING (ORBITER COMMUNICATIONS) 


Instructions Data Total Storage 

Functions (16 Bit) (32 Bit Wd) '(32 Bit Vld) 

0 38 

0 38 

3556 3800 


Assure Instrumentation Control 75 

SUBTOTAL 75 

TOTAL ‘ ■' 487 


SPEED REQUIREMENTS 



1000 KAPS 
150 KAPS 
1150 KAPS 


(1) Assuming 16 equivalent add operations per 16 bit data word in 

6 

processing 1.0 x 10 bits per second. 


CONTROL AND MONITORING 

Not applicable for this technique. 



1 • 


Table 4. 4.3-5 POST DATA PASS 


STORAGE REQUIREMENTS 


DATA PROCESSING 
Functions 


Instructions Data Total Storage 

(16 Bit) (32 Bit Wd) (32 Bit Wd) 


Standard Linkage 

24 

20 

32 

Set Up to Access UHD Tape that 
was Created during Real Time Pass 

12 

6 

12 

Buffer Selected Data from Tape 
via Micro-Processor #1 into 1.5 
and 6.0 Mbit Auxiliary Storage Areas 

50 

20 

45 

Access 1,5 Mbit Auxiliary Storage 
with MEDI Computer, 

20 

3200* 

3210 

Prep Data and Perform Initial 
Calculations on Key Parameters 

500 

100 

350 

Prepare Data for Display 

60 

20 

50 

Transmit Data to lOP D — ►A 
Converter, Process, Sync, 
Interlace and Display Video Data 

150 

256 

331 

Transmit Data via RAU to CDMS 
Computer and Display Key 
Parameters 

60 

30 

60 

Perform Updated Calculations 

300 

100 

250 

Display Updated Parameters 

60 

30 

60 

Provide Plot Capability on 
Image Data 

400 

120 • 

320 

Standard Return Logic 

20 

0 

10 

SUBTOTAL 

1656 ' 

3902 

7430 


^Approximately 10 fetches per second. 
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Table 4.4. 3-5 POST DATA PASS (Continued) 


CONTROL AND MONITORING/ (ORBITER COMMUNICATIONS) 


Functi ons 

Instructions 
{16 Bit) 

Data 

(32 Bit Wd) 

Total Storage 
(32 Bit Wd) 

Assure Instrumentation Control 

o 

o 

t — 1 

20 

70 

SUBTOTAL 

100 

20 

70 

TOTAL 

1756 

3922 

4800 


SPEED REQUIREMENTS 

DATA PROCESSING 

= 2000 KAPS 

300 KAPS 
2300 KAPS 

(1) Assuming 32 equivalent add operations per each 16 bit data word in 
processing 1.0 x 10^ bits per second. 


CD 

Speed = 1.0 X 10° x 32 
16 

plus 15% overhead 
TOTAL REQUIREMENTS 


CONTROL AND MONITORING 

Speed = 100 x 1.5 = 0.150 KAPS 
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4.5 OPERATIONAL PROCEDURES 


The EO-06-S Integrated Interaction System provides for a means to reduce 

data quantity during scheduled and unscheduled data takes and it provides 

a means to obtain reasonable assurance as to quality of the data take in 

real time. The scheme provides also for the timeliest possible way to 

assess the data take short of ground site assessment (which by requirement 

is not intended and by the extremely high data rates not likely to occur). 

» 

4.5.1 Real Time Operation 

In real time, the experiment operator may choose to engage the interactive 
system. Basically, five methods of interacting with the data are available. 
The desired method of interaction chosen by the experiment operator is 
selected by keyboard selection from the Payload Specialist Station (PSS). 

Real time "Quick Look" for data collection systems performance is available 
for selection with or without additional automated real time screens. MSS 
spectral bands/channels may be selected one at a time and their respective 
real time data can be displayed as scene or image data by standard onboard 
TV. Data collection system performance may be monitored in this manner. 
Timely corrective action may be taken in the event of system malfunction or 
data degradation due to noise pollutants, etc. 

The Spectral Condition Detection technique is selectable from the PSS when 
any given spectral condition prevalence is sufficient to determine whether 
the terrain under observation has the features desired rendering it, in 
turn, as "good" or "bad" data. This provides for rapid, automated ground 
data processing and also provides for a rapid scan and evaluation of data 
during the post data pass period. The technique may be manually terminated 
or timer "time-out" terminated. 
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The Ground Beacon Control of the data take is selectable from the PSS when 
ground track is anticipated to be in proximity of the beacon designated 
target. Since the- beacon is directional, small but appropriate orbiter 
maneuvers (roll) may be expected to align the MSS line of sight with the 
beacon. The RECORD operation commences with signal alignment and ceases 
by manual control, timer “time-out'' or loss of a signal. 

The Fully Automated Data Take Controls is also a real time data quantity 
screen selectable from the PSS when a schedule of targets with coordinates 
are supplied from mission control. When this mode of data take control 
is selected all intended targets are scheduled and the data take is completely 
automated until manually terminated, timer "time-out" terminated or all 
scheduled targets have been observed. Targets not observed (system mal- 
function, etc.) are made available for rescheduling. Though not necessary, 
it seems desirable' to use this screen in conjunction with the Spectral 
Condition Detection technique. 

4.6.2 Post Data Pass Operation 

For the Post Data Pass period of the orbit time is available to the experiment 
operator/scientific investigator to utilize for assessing in detail the data 
take effort, i.e., did the data gathering system perform correctly at all times 
were all desired targets observed, are there incidentally acquired targets 
worthy of further investigation, are there any analysis techniques that can 
be applied to the data that has been collected? The Post Data Pass Screen 
when selected will provide for data tape read, scene display and interactive 
data analysis tools such as CRT plots and the simpler statistical and mathe- 
matical calculation routines. 


4.6 COST/BENEFITS ANALYSIS 

A groundrule that has been used in estimating hardware costs for the 
elements of the E0-06-S interaction system (all of which must be purchased) 
is that standard laboratory equipment (off-the-shelf equipment) can be 
utilized. This is concluded after assuming that the IGLOO can be used 
to house these elements during pallet mounted experiments. If pallet 
mounting is required due to insufficient IGLOO volume, then a factor 
relating standard laboratory equipment costs to space-qualified equipment 
must be applied to increase all affected cost estimates. 

Table 4.6-1 lists the estimated cost for the 1980 time frame for the E0-06-S 
intcfraction equipment. All numbers are rough “order-of-magnitude" estimates 
only. Significant factors that are foreseen and that can influence these 
estimates are: ' 

t Microprocessor #1 - Will be a new item for development and 
it will consist of a customer tailored I0P( Input/ Output 
Processor) built around an off-the-shelf CPU. 

• Microprocessor #2 - See previous item. 

t MEDI Computer - Will be the latest state-of-the-art commercial 
computver with a 16K memory (an advanced PDP-irfor instance) 
with interrupt processing capability and standard I/O modules 
being assumed. 

• Auxiliary Storage Device - Cost projections for this device are 
based on present bubble memory and CCD (Charge Coupled Device) 
technologies of 0.02(t per bit. For the 7.5 Mbit storage 
requirement, an additional $50,000 development cost has been 
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assumed for each storage module (one 1.5 Mbit and one 6.0 
i^bit). Development costs would be associated with any unique 
organization of the memory chips into desired input and 
output formats j packaging, etc. 


Table 4.6-1 E0-06-S INTERACTION HARDWARE COST ESTIMATES 


Item 

Cost 

Channel Selector 

$25,000 

Microprocessor #1 

$250,000 

Microprocessor #2 

$160,000 

MED I Computer 

$80,000 

Auxiliary Storage Device 

$101,500 


Software cost estimates are listed in Table 4.6-2. Based on both Skylab 
and Saturn onboard and ground operations software a value of $20.00 per 
instruction is used. Each instruction is assumed to be 16 bits. 

Table 4.6-2 E0-06-S SOFTWARE COST ESIMATES 


Interactive Techniques 

Instuctions 

Total Cost 

Spectral Condition Detection 

1201 

$24,020 

Ground Beacon Control 

833 

16,660 

Fully Automated Data Take 


* ■ 

Controls 

1072 

21,440 

Real Time “Cjuick Look'' 

487 

9,740 

Post Data Pass 

1756 

36,120 

TOTAL 

5349 

$106,980 



Final savings estimates are based upon Skylab Earth Resources Principle 
Investigator (P.1,) quotes obtained from the Phase. II fact finding trips. 

It was stated that fully 80% of all data obtained could have been eliminated 
as unnecessary by the interested, knowledgeable experiment operator when 
given the appropriate detection capabilities and means to exercise visual - 
judgmental faculties peculiar to the experimeriter. Additionally, even 
valid data was found on occasion to be degraded by noise contamination, 
calibration source time changes, etc. This proportion of degraded data 
that must be corrected by extensive ground processing is assumed at 5% 
(minimum) to encompass. actual data quality improvements obtained by inter- 
action. A total of 85% data quantity reduction is foreseen as listed in 
Table 4.6-3. 

Table 4.6-3 DATA QUANTITY REDUCTION 

Technique Data Quantity Reduction 


Spectral Condition Detection 

40%) 

Ground Beacon Control 

o 

CO 

Fully Automated Date Take Controls 

35% j 

Real Time "Quick Look" 

5% 

Post Data Pass "Scan" 

2%) . 

TOTAL 

85% 


Interaction savings are realized from the 85% reduction in data to be 
processed. The quantity of data to be processed without interaction control 
is computed at 3.35 x 10^^ bits/mission (i .e. , 0.41875 x lO^^ bytes/mission) 
Total CPU time to process this data is based on the algorithm that uses 
40 ysec CPU time to process each byte of data. CPU time computed to process 
3.35 X 10^^ bits is 4643 hours, CPU time v/hen purchased to process the 
data is computed to be $1,216,466. Labor cost (minimum) is $46,430 for a 
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total processing cost estimate of $1,262,895. An 85% reduction therefore, 
in data processing costs saves $1,073,462 (minus the first time cost of the 
interaction hardware and software). Savings for the first flight is 
$1,073,462 minus $723,480 or $349,982. Savings for the second and sub- 
sequent flights are $1,073,462 per flight. Additional savings that are 
less quantifiable but, nevertheless, Just as valid, are to be anticipated 
for reduction in tape storage facilities, tape costs and data archiving. 

A savings is also anticipated in the area of increased scientific data 
value. This can be based on data 'freshness' obtained from quicker total 
data evaluation that is made possible by reduced data processing time. 

A more subtle and also non-quantifiable benefit is that derived from 
improved mission productivity through the visual tools made available to 
the experimenter to assess each data take in such a manner as to permit 
a data retake, etc., before the mission has terminated (the cost or the 
possibility of a r^flight has not been evaluated). 



5. STUDY RESULTS AND CONCLUSIONS 

Spacelab User Interaction Study results and conclusions from the SO-Ol-S 
and E0-06-S interaction systems development study point solidly to the 
profitability in terms of scientific value and dollars of this means of 
effecting a reduction in data quantity and an improvement in data quality. 

The SO-Ol-S and E0-06-S payloads have been utilized as typical, interaction 
amenable payloads suitable, ultimately, for actual demonstration of the 
value of the interaction systems proposed. 

The Solar Physics and Earth Resources communities in the areas of investi- 
gation and sensor development have been interviewed to access their unique 
relevant experience. Their suggestions were factored in with other basic 
inputs to the Phas-e II study. From the Phase II development of a number 
of payload applicable interaction techniques, an integrated interaction 
•system for each of the two payloads has been 'developed by the Phase III 
study. The SO-Ol-S and E0-06-S Integrated Interaction Systems have been 
functionally defined and are accompanied with corresponding hardware block 
flow diagrams, hardware specifications, software sizing and speed requirements, 
operational procedures and finally cost/benefits analysis data for both 
onboard and ground based system elements. The cost/benefits analysis for 
SO-Ol-S and E0-06-S show that accrued benefits, dollar-wise, are attributable 
to a reduction in data processing costs obtained by, generally, a considerable 
reduction in the quantity of data that might otherwise be generated without 
interaction. Reduced data processing costs include reduced CPU time, CPU 
operations personnel, and data storage, turnaround and archiving as savings 
areas. Cost benefits were justified in two: areas of savings only; naimely, 

CPU time and CPU operational personnel because of the easily quantifiable 
nature of these two areas and their sufficiency to monetarily justify the 
need fcr interaction. 
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12 

Detailed analysis of the SO-Ol-S payload which can generate 6,0 x 10 
bits per 7-day mission substantiates a data quantity reduction of 55%. 

This translates into a savings of 4583 hours of CPU processing time and 
4583 hours of CPU operational personnel time valued at $1,245,000. This 
benefit to be obtained on each 7-day mission for SO-Ol-S is offset by a 
one time cost of $612,720 to implement the interaction system into the 
payload. 

In similar manner analysts of the E0-06-S payload which can generate 3.35 
12 

X 10 bits per 7-day mission, substantiates a data quantity reduction of 
85%. A data quantity reduction of 85% translates into a savings of 3947 
hours of CPU processing time and 3947 hours of CPU operations personnel time 
which is valued at $1,073,462. This benefit is repeated for each 7-day 
mission for E0-06-S, The benefit is offset by a one time cost of $723,480 to 
implement the interaction system into the payload. 

'There are other additional savings anticipated, but which are not easily 
monetarily measured such as increased scientific value obtained by the 
quicker return of all useful data that is made possible by the reduced 
time to process the data from a mission, i.e. , the positive value of data 
'freshness' has not been quantified. For both payloads, there is also a 
very positive benefit in improved productivity for the mission that is 
realized through the visual tools made available to the experimenter enabling 
him to see his targets in the non-visible spectrum. These tools, for earth 
resource payloads, will also enable the experimenter to schedule data retakes 
etc. before the mission is terminated if a scheduled target was not adequately 
scanned for any reason. Again, benefits have not been quantified for 
saving the cost of a possible reflight. 

In conclusion, the results of the Spacelab User Interaction Study have 
produced a compendium of good techniques (Phase II) for two typical' Spacelab 
payloads. From the techniques, an integrated interaction system has been 
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developed that v/hen analyzed from a cost versus benefit viewpoint, yields 
good evidence capable of justifying the benefits of interaction. The 
evidence generated by this study is sufficient to demonstrate that at this 
point in the Shuttle era a continuing effort to investigate, generalize and 
demonstrate interaction for payloads other than E0-O6-S and SO-Ol-S within 
the Solar Physics and Earth Resources disciplines should be pursured. Ex- 
tension to other disciplines that are interaction amenable must also be 
considered. 


6. CONSIDERATIONS FOR FUTURE STUDY 


Phase III of the Spacelab User Interaction Study concludes that interaction 
is a beneficial, even' necessary , requirement for two Spacelab payloads, 
SO-Ol-S and E0-06-S. The study work product (i.e., integrated system defi- 
nition, design, hardware specifications, software requirements and operations 
procedures) and cost/ benefits analysis strongly recommend a continuation of 
such activity as would lead ultimately to implementation. 

Interaction, logically, should be directed into the area of preparation 
for demonstration, demonstration being necessary to validate the interaction 
concepts prior to onboard and ground system implementation and integration. 

Follow on that is recommended should include all of those items detailed 
for future work to'follow Phase III that were set forth in the Phase II 
report. They were: 

« Utilize the current study results and generate an interaction 
demonstration plan. The task would define a systems plan to 
validate the interaction* concepts and to include the associated 
demonstration, 

• Broaden the scope of the baseline interaction systems to 
include all payloads within the respective disciplines. 

• Perform compatibility analysis studies to design an inter- 
action system for multi -discipline payloads and examine the 
baseline interaction systems for necessary modifications 

to generate a distinct system applicable to all of the 
Spacelab experiment di scipl ines . 
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Integrate the final interaction system into the total Space! ab 
data flow performing an investigation to determine the impacts 
on the Spacelab subsystems resulting from implementation of the 
interaction system. It is desirable to perform this effort in 
such a manner as to benefit from any time delays necessary to 
perform the other tasks of the follow on work. This would permit 
Spacelab experiment and subsystem definitions to evolve signi- 
ficantly along with a final principle investigator designation 
for each experiment. Certain pacing items are foreseen as 
requiring additional time to mature prior to a final inte- 
gration and implementation effort. 



